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 - rain...@eldwood.com
