Fully dynamic d by opDotExp overloading

[Nick Sabalausky]

"Rainer Deyke" <rainerd at eldwood.com> wrote in message 
news:gsbodm$mjc$1 at digitalmars.com...
> 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.
>

If the member-name parameter to opDotExp was *required* to be a template 
paramater, then I agree, and I would have no objections to having that. But 
it should be pointed out that that would not actually be dynamic invokation, 
since you wouldn't be able to invoke a member whose name is only known at 
run-time. (But I would love for that to be possible through a reflection 
API.)