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