On 8/10/2014 6:52 PM, Era Scarecrow wrote:
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)}]},
It's not ideal, but it gets the job done. Keep in mind that you are proposing to
use withs to mix up multiple enums with lots of members - name clashes are very
possible, and there's no visual clue which enum a name belongs to. It merges
multiple scopes together without collision detection.
I'm not so sure it is desirable. It does save some typing, but at another
increase in language complexity, which has costs as well.
