Yigal Chripun Wrote: > On 24/10/2009 17:10, Denis Koroskin wrote: > > On Sat, 24 Oct 2009 19:00:10 +0400, Justin Johansson <[email protected]> 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?
