enums and version/static if/"inheritance"

IchorDev zxinsworld at gmail.com
Thu Aug 1 02:06:39 UTC 2024


On Wednesday, 31 July 2024 at 19:03:32 UTC, Walter Bright wrote:
> Indeed, it does. Consider the evolution of expertise:
> 1. novice - follows the rules because he's told to
> 2. master - follows the rules because he understands the point 
> of the rules
> 3. guru - violates the rules because he understands when the 
> rules don't apply

He this, he that. Where is ‘they’ when you need it?
Nonetheless, when you say to do things one way, people will feel 
that they have to follow. I’ve seen a **lot** of horrendous enum 
repetition in D because of this mentality that ‘we have to do 
things the bad way because it’s correct’. Before I took over 
BindBC-SDL it had **so** much repetition because of this design 
pattern. I replaced all the enum types with typeless lists, but 
now people can’t just iterate over the members of an enum 
properly. Relegating something that’s easy to do anywhere else 
(structs, unions, classes) to mixins is just cruel and encourages 
people to make unreadable or inferior code because it’s the path 
of least resistance. Not everyone will spend a day making an enum 
generator like I did; and it didn’t even occur to me 2 years ago 
to use a mixin for enums in the case of BindBC-SDL because there 
was this dogma.

> BTW, your example looks fine as it is!

You said that it hurts your head to read code like that. But even 
if it’s ‘fine’, it would compile faster & take fewer lines if we 
could put conditional compilation in comma-separated lists, 
particularly enums and (associative) array literals. I would only 
need to write one array literal instead of a CTFE lambda with a 
series of ifs. Notice also that I did not nest those ifs, which 
is slightly worse for performance, but I had to preserve 
readability. With a single array literal, I would not have to 
make these compromises.


More information about the Digitalmars-d mailing list