Fully dynamic d by opDotExp overloading

[Steven Schveighoffer]

On Fri, 17 Apr 2009 18:01:51 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message  
>> news:gsapl6$24ei$1 at digitalmars.com...
>>> Steven Schveighoffer wrote:
>>>> Sure, how do you know that the class actively chose it, or did not  
>>>> actively choose it, or will *never* actively choose it simply by  
>>>> looking at the statement?
>>> You shouldn't worry about it as much as you shouldn't when you iterate  
>>> a built-in array vs. a user-defined range.
>>>
>>> Would you like ranges that work very different from built-in arrays,  
>>> and everybody to special-case around that?
>>>
>>  That's an inadequate comparison. We *can* make arrays and ranges  
>> usable in the same way. But opDotExp cannot make dynamic calls usable  
>> in the same way as static calls, because one of the rules of static  
>> method invokation is that trying to call a non-existant function  
>> results in a compile-time error. The best opDotExp can do it make  
>> dynamic calls *seem* the same which is deceptive.
>
> Au contraire, it's a very adequate comparison. We changed the language  
> to support ranges/arrays uniformly. Here, I'll paste your argument with  
> the appropriate changes:
>
> ====
> But globals acting as members cannot make arrays usable in the same way
> as user-defined types, because one of the rules of arrays is that trying  
> to call a non-existant member function on an array results in a  
> compile-time error. The best your rule can do it make nonmember calls  
> *seem* the same which is deceptive.
> ====

Calling global functions as if they were array members does not subvert  
the type system.  It is not even close to the same level of danger that  
this is.

I'm all for expanding runtime introspection that remains within the type  
system, I'm even for adding some possibility to create dynamically  
dispatched functions, as long as those functions are called differently  
 from normal functions.

I think you would agree that one of the main roles of the compiler is to  
prevent you from making mistakes before it even gets to runtime.  Without  
knowing which calls the compiler checked and which ones it didn't, I can't  
know where to spend time scrutinizing.

>> If you want static and dynamic calls to be really usable in the same  
>> way (like iterating over a range vs array), then there's only two  
>> possibilities:
>>  1. Make attempts to invokation a non-existant static function a  
>> runtime error (obviously a bad idea).
>> or
>> 2. Provide a *secondary* syntax to invoke a method that works for both  
>> static and dynamic. Such as through a reflection api:
>>  traits(new Foo()).invokeMethod("bar");
>
> If I want to write an algorithm that calls "bar" twice, it should be:
>
> void twix(T)(T value)
> {
>     value.bar();
>     value.bar();
> }
>
> NOT
>
> void twix(T)(T value)
> {
>      static if (isDynamicType!T)
>      {
>          value.invokeMethod("bar");
>          value.invokeMethod("bar");
>      }
>      else
>      {
>          value.bar();
>          value.bar();
>      }
> }
>
> Please at least acknowledge that you are in receipt of this argument.

I think Nick's point number 2 is that you would have to write the above as:

void twix(T)(T value)
{
       value.invokeMethod("bar");
       value.invokeMethod("bar");
}

which would work whether bar was dynamically or statically defined.

>
> We are discussing a language extension. That language extension will  
> allow a type to choose flexibility in defining methods dynamically,  
> while being otherwise integrated syntactically with the current values.  
> This has advantages, but also alters the expectations.

As long as it identifies what can be dynamic and what cannot.  I can't  
imagine Walter will go for this with his strict view of hijacking.

-Steve