Fully dynamic d by opDotExp overloading

Yigal Chripun yigal100 at gmail.com
Sat Apr 18 00:38:31 PDT 2009


On 18/04/2009 10:24, Andrei Alexandrescu wrote:
> Yigal Chripun wrote:
>> On 18/04/2009 04:54, Steven Schveighoffer wrote:
>>
>>> 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.
>>>
>>> -Steve
>>
>> Here's an idea:
>> Allow the use of this feature _only_ for appropriately marked types.
>> dynamic class A {... opDotExp ...} //compiles
>> dynamic struct B {... opDotExp ...} //compiles
>>
>> class A {... opDotExp ...} // compile-error: "please mark class as
>> dynamic"
>> struct B {... opDotExp ...} // as above
>>
>> now you have an easy way to know if a type is dynamic without changing
>> the method invocation syntax. A proper IDE can easily mark those Types
>> as different, for example, using a different color.
>
> The dynamic behavior is indicated by the use of opDotExp. The redundancy
> of the two notations doesn't quite sit well.
>
> Andrei

right.
The opDotExp should be synthesized by the compiler for dynamic types.
instead of:
class A {
     Variant opDotExp(string name)(args...) {
         static if(name == "foo") { ... }
         else { ... }
     }
}

you'd have:
dynamic class A {
      int foo(args) {...}
      ...
      Variant methodNotFound(args...) {/*same as the else clause above*/}
}

the first would be generated from the second.

It just seems to me to be slightly better looking syntax, since this 
whole discussion is mainly about syntax.
I don't know if it is worth the change, but if we already discuss a 
change to the compiler... plus it's easier to spot those dynamic types 
with this syntax for humans and programs.



More information about the Digitalmars-d mailing list