Re: [boost] Enums: naming question?

Subject: Re: [boost] Enums: naming question?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-21 08:03:24

Vicente Botet wrote:
> Jeffrey Lee Hellrung, Jr.-2 wrote:
> > <vicente.botet_at_[hidden]>wrote:
> >
> >> I need some traits, to get the native type from the
> >> emulation, and the coping class from the native one. In
> >> addition there is an underlying type that is used to store
> >> the enumerators. Next follows the names I have use in the
> >> library:
> >>
> >> native_type::type
> >> underlying_type::type
> >> scoping_type::type
> >>
> >> In addition I have defined some functions that make the
> >> conversions from these types
> >>
> >> template
> >> native_type::type native_value(ScopedEnum e);

I receive your message as plain text and the <'s and >'s are missing.  I'm not using gmail as my client, so it would seem to be something on your end.

> >> template
> >> underlying_type::type underlying_value(ScopedEnum e);
> >>
> >> I have defined all these under the boost::enums namespace.
> >>
> >> Do you have a better proposal for these (meta-)functions?
> >
> > Perhaps you can summarize what these types and (meta-)
> > functions are suppose to be/do?
>
> When scoped enum classes are available we can use
>
>   enum class EnumClass : short {E1, ... En};
>
> In this case the scoped enum class is already an enum.
>
>   is_enum::value is true
>   typedef EnumClass EnumClassNative;
>   native_type::type is EnumClass
>   underlying_type::type is short
>   scoping_type::type is EnumClass

Your use of "*_type::type" is redundant.  Why not "underlying::type" instead of "underlying_type::type," for example?

In this case, EnumClass is the "scoped enumeration" type, just based upon the standard's naming, right?  Thus, "scoped_enum::type" (or "scoped_enumeration::type") would seem right.

"underlying" is a reasonable term for the storage type, though "storage type" seems more to the point.  From the grammar, it is the enum-base and "enum_base::type" would work very well.

That leaves "native_type."  More on that below.

> When scoped enum classes is not supported the emulation uses
> the well known schema
>
>     template
>     class EnumClass
>     {
>     public:
>       //! c++98 enum type
>       typedef enum {E1, ... En} type;
>       //! underlying type
>       typedef short underlying_type;
>     private:
>       underlying_type val_;
>     ...
>     };
>
> and of course EnumClass is not an enum :(
>
>   is_enum::value is false
>   typedef EnumClass::type EnumClassNative;
>   native_type::type is EnumClassNative
>   underlying_type::type is short
>   scoping_type::type is EnumClass

Since "native_type" is a fabrication to account for the implementation distinction between the emulation and native scoped enums, "native" hardly seemed the right adjective at first.  Upon reflection, it occurs to me that it refers to the native enumerated type within the two mechanisms, so perhaps it works well after all.  Since the point is to determine the enumerated type in the scoped enumeration, "enum::type" would follow the pattern of my earlier suggestions using "enum" in the name, but that, of course, won't do.  BTW, "underlying" may be an appropriate adjective for this aspect.

Here are two options, summarized from the previous discussion:

 Your Names          Option 1        Option 2
-----------------------------------------------
native_type     enumeration         native_enum
underlying_type enumeration_storage enum_base
scoping_type    scoped_enumeration  scoped_enum

Obviously, Option 2 uses shorter names which are preferable all others things being equal, and it uses the term from the grammar (enum_base).

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.