Private enum members + Descent

[Justin Johansson]

Yigal Chripun Wrote:

> On 24/10/2009 17:10, Denis Koroskin wrote:
> > On Sat, 24 Oct 2009 19:00:10 +0400, Justin Johansson <no at spam.com> wrote:
> >
> >> Yigal Chripun Wrote:
> >>
> >>> On 24/10/2009 01:16, Justin Johansson wrote:
> >>> > Sorry; subject line mod'ed just so Ary doesn't miss it.
> >>> >
> >>> >> enum Color { private UNINITIALIZED = -1, RED, GREEN, BLUE }
> >>> >
> >>> >> (btw. Interestingly, typing this code into Eclipse with the
> >>> Descent plug-in
> >>> >> causes a Java out of heap space malfunction.)
> >>> >
> >>>
> >>> enum Color { RED, GREEN, BLUE }
> >>>
> >>> void foo(Color* c) {
> >>> if (c !is null) handleColor(*c);
> >>> }
> >>> what's the need for that UNINITIIALIZED member?
> >>
> >> Okay; that's one work around for a corner case of my cited use-case, but
> >> you don't always want to, or perhaps it is not convenient/elegant to,
> >> use a pointer
> >> to data that conveniently fits into a machine register.
> >>
> >> Perhaps I am wrong but I thought uninit was a good metaphor to
> >> demonstrate
> >> the various useful purposes that private enum members might have.
> >>
> >> Here is another example that might make the concept jell. Again I may
> >> well be wrong.
> >>
> >> Consider this hypothetical enum definition together with plausible
> >> comments:
> >>
> >> enum Color {
> >> RED, GREEN, BLUE, // these 3 members are available for public consumption
> >> private RED_WITH_BLUE_POKER_DOTS, // this value is used internally and
> >> is not for public consumption and that's why it is marked private
> >> private RED_OR_GREEN, // ditto; internal routine to cater for
> >> red-green color-blindness
> >> }
> >>
> >> The above demonstrates a set of entities that are meaningful to some
> >> possible internal
> >> function but otherwise not externally meaningful.
> >>
> >> Another use-case lies in the API programmer's want for "private" ..
> >> so, for example, consider that "private" may well be a synonym for
> >> "pleasedontusethismemberbecauseitisalikelycandidateforfuturedeprecation"
> >> **
> >>
> >> ** Using Walter Bright insignificant whitespace/separator notation :-)
> >>
> >> Thanks Yigal for commenting and perhaps your further comment?
> >>
> >> Justin
> >>
> >
> > Another useful use-case I see is enforcing explicit initialization:
> >
> > enum Color
> > {
> > private Uninitialized = 0,
> > Red,
> > Green,
> > Blue,
> > }
> >
> > Color color; // error: Color.Uninitialized is not accessible
> >
> > It would work similar to private struct ctors.
> 
> 
> I'd prefer D to have support for:
> 
> enum Color { Red, Green, Blue }
> 
> Color color; // compile time error
> Color? color; // OK
 
> I don't understand why would you want to hide certain enum values. In 
> the colors example above, what's the rational behind hiding the 
> RED_OR_GREEN value?

Let me try again.  You have a set of N things which are represented by
an enum definition.  There is some subset of this set containing M
things (so M < N) which represents the things meaningful in a public
sense.  The remaining Q=N-M members of the whole set are only meaningful
to some internal processing so this subset containing Q members are
designated private.  I'm trying to think about this problem in an abstract
way; sometimes giving concrete examples like Color colors (pun intended)
the abstract problem.

Maybe there is no good physical example and therefore I am wrong.


> personally I'd like to see D enums replaced by Java style enums which 
> make more sense to me. D enums are even worse than C enums since you can 
> write:
> enum foo = "text";
> 
> which to me looks very similar to:
> auto cat = new Dog;

I didn't know this one.  It does sound like the design of D enums needs revisiting.
Perhaps others will chime in on this?