On Sat, 28 Nov 2009 00:30:14 +0100, Walter Bright
<newshou...@digitalmars.com> wrote:
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
In D, this:
s.foo(3);
could be emulated with:
s.dynamicMethod("foo", 3);
Unfortunately, that makes it impossible to use s with generic code
(besides looking unappealing). But with a small feature, we can make
this work:
struct S
{
...
T opDynamic(s : string)(args...);
}
and then s.foo(3), if foo is not a compile time member of s, is
rewritten as:
s.opDynamic!("foo")(3);
and opDynamic defers all the nuts-and-bolts of making this work out of
the language and into the library.
In particular, opDynamic's parameter and return types should all be
instances of std.variant.
(This has come up in various forms in this n.g. before, but I don't have
any references handy.)
davidl implemented this as opDotExp in "Fully dynamic d by opDotExp
overloading"
(http://www.digitalmars.com/webnews/newsgroups.php?article_id=88145).
I'd really like to see this. Is there a reason to allow only std.variant as
parameters? I can easily see this being used where the type (or set of
possible types) is known at compile time, but one does not want to
implement
a lot of boilerplate functions.
Also, would the generated functions be usable as @propertys?
--
Simen
