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.
