proposal: allow 'with(Foo):' in addition to 'with(Foo){..}'

Era Scarecrow via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 10 18:52:40 PDT 2014


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)}]},


More information about the Digitalmars-d mailing list