Fully dynamic d by opDotExp overloading

[Andrei Alexandrescu]

Nick Sabalausky wrote:
> "Nick Sabalausky" <a at a.a> wrote in message 
> news:gsbru0$rb6$1 at digitalmars.com...
>> "Don" <nospam at nospam.com> wrote in message 
>> news:gsbovk$nbj$1 at digitalmars.com...
>>> The problem is a lack of notification at compile time. Runtime exceptions 
>>> are the problem, not the solution.
>>>
>>> By the way, if the opDot is a template (per Andrei's suggestion), then if 
>>> it is marked as nothrow, you have a guarantee that if it compiles, it's 
>>> valid.
>>> nothrow opDot(char [])(args...) doesn't have any of the problems which 
>>> Nick et. al have mentioned.
>> Ok, now *that* is something I can be happy with.
>>
> 
> In fact, now that I think about it, as long as the member name was required 
> to be a template parameter, I'd be perfectly happy with it (and wouldn't 
> even want nothrow to be required).
> 
> I think that's slightly different from what Andrei's advocated though. 
> Unless I misread something, Andrei, you want it to be possible for the 
> member name to be *either* a template or non-template param, right? 
> 
> 

I think there's a confusion somewhere. Are you sure you know what you 
don't like? :o)

It's simple, really. First off, there's no way you can pass a variable 
string as a method name with a regular syntax:

string foo = "bar"';
Dynamic d;
d.foo(); // passes "foo", not "bar"

I hope this clarifies that confusion.

If you want to invoke a method known as a string variable, opDot or 
whatever has nothing to do with it. You don't need any change to the 
language at all, because you'd write:

string foo = "bar";
d.call(foo); // call method bar

What opDot does is to allow the regular member syntax while still 
allowing the callee to look up the name statically or dynamically 
(assuming the method name is passed into opDot as a template parameter). 
  Note, again, that opDot has everything to do with the syntax and next 
to nothing to do with the semantics, which is realizable without any 
change in the language. And that's how the cookie crumbles. I understand 
you don't like that, but at least we should be clear on where the 
feature starts and where it ends.


Andrei