dynamic classes and duck typing

[Simen kjaeraas]

On Sat, 28 Nov 2009 00:30:14 +0100, Walter Bright  
<newshound1 at 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