On Monday, 11 August 2014 at 00:23:36 UTC, Walter Bright wrote:
I'd suggest simply:
private alias FlagStates FS;
then use FS.def, etc.
The source code has 400 lines (955-1376) where it uses flags of
one kind or another. Constantly having to add that type of thing
in just fills up space without telling a lot of information.
Aliasing makes it smaller, but the problem is still there.
Feels like backtracking to hungarian notation. In a large bulk
data I know the data type is of certain types because I need to
throw them in a templated/static constructor that handles them
anyways. Having to do it a second or third time just bets
uselessly verbose. It's why auto is so nice where you don't have
to explicitly state everything when you really don't need it to
be there. It just clutters it, like 1,000 times at least...
There's no mystery of what data goes where, and the enums can
only enter in certain formats so having lots of (this
boilerplate) code to describe what it is and where it's from.
Mind you this is a public statically declared global known at
compile-time...
Maybe i'm hoping for too much...
Original: {ValueType.raw, "Height Data", 4228,
Flags(FlagStates.noChange, FlagStates.noPrintClashes,
FlagStates.hashPrint)}]},
//2 shorthand aliases as you suggest, a bit better
Becomes: {VT.raw, "Height Data", 4228, Flags(FS.noChange,
FS.noPrintClashes, FS.hashPrint)}]},
//a dozen private aliases, only the most common that clutter code
currently: {VT.raw, "Height Data", 4228, Flags(noChange,
noPrintClashes, hashPrint)}]},
preferable:{raw, "Height Data", 4228, Flags(noChange,
noPrintClashes, hashPrint)}]},
