Fully dynamic d by opDotExp overloading

[Rainer Deyke]

Nick Sabalausky wrote:
> But anyway, like I've said before, syntactic sugar is fine, but this is 
> syntactic sugar that undermines the programmer's ability to rely on 
> compile-time checking of class members. "But only for the classes that use 
> it." No, it undermines that trust across the board because it's non-obvious 
> what classes are using it, so you'd have to always be on guard. "Operator 
> overloading blah blah blah" That only causes problems when it's used *and* 
> abused by a class, while this would cause problems *any* time it's used. Etc 
> etc...

Compile time checking is not undermined at all, even for classes that
use this functionality.  opDotExp just makes it easier to create classes
with a large, possibly infinite set of members.  There are three
possible cases:

1. The class does not use opDotExp.  Compile time member checking is not
undermined.

2. The body of opDotExp triggers an error at compile time if it receives
an unexpected name.  Compile time member checking is not undermined,
although the specific error message may have changed.

3. The body of opDotExp accepts all names.  Compile time member checking
is not undermined, we just have a class that has every legal identifier
as a member.


-- 
Rainer Deyke - rainerd at eldwood.com