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