From: Eric Friedman (ebf_at_[hidden])
Date: 2003-11-12 18:33:10
Andy Little wrote:
> The metafunction naming style that instantly came to mind for me
> and honestly thought was in use ( as a newbie to MPL) was to add a '_t'
> to the name, hence
This is not the convention used by MPL.
> the precedent for this is the "wchar_t", "time_t","clock_t" etc types.
These types you cite as 'precedent' are not metafunctions. They are
regular types. That is, you *never* write:
> Its also much shorter to type and the suffix reflects the position of the
> ::type in the useage.
> The user feels a natural urge to 'fill in' the "_t" with a "::type".
> of course you could do more typing, but redundant typing is redundant :-)
I don't see how either the name MyWidget_t or MyWidget_type suggests to
the user a metafunction (i.e., that a trailing ::type is required). As I
wrote in my previous post, I believe this is because they are nouns.
A noun suggests a completed state, whereas what needs to be conveyed is
a transformation (i.e., a function from one type to another).
> (steering clear of the name metafunction as I may be using incorrectly )
I think you may be.
> with the metawidget returning a value the obvious choice is "_v"
I don't think this is obvious. I don't even think I've seen it before.
> this extends the "wchar_t" precedent of course to fit the MPL world
Again, I think you're off with your 'precedent' here. Further, adding a
trailing _v is not an MPL convention.
> As a newbie to metafunctions I find the "make_x" style odd. I dont want to
> "make" anything.
Yes, you do. You want to make a recursive variant type. As I said,
though, I'm not committed to "make"; I just haven't seen another verb
> That suggests run time hence "weak" from an MPL point of view. Hopefully as
> a user by the time I use it it has already been "made"
> I see MPL types as "hard immutable" things "metamorphed", "ground from"
> ,"chiselled f rom" my arguments at compile time,
> unlike the weak and wibbly wobbly entities of runtime.
I think the trailing ::type is a good indicator that there is no runtime
> Apologies for wading in... but I feel much better with that off my chest :-)
No problem, but what I'm aiming for is to choose a name that is most
likely to prevent misuse that is difficult to identify. I'd argue even
an ambiguous name is better than one that is falsely unambiguous: the
the former will quickly send the user to the documentation; the latter
will leave the user confused.
So again: "I plan to leave the names as make_recursive_variant, etc.
unless someone proposes another verb phrase that is better."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk