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.)

Walter Bright 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.)

One of these is the thread "Fully dynamic d by opDotExp overloading".

Andrei

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

Simen kjaeraas wrote:
> davidl implemented this as opDotExp in "Fully dynamic d by opDotExp overloading"
> (http://www.digitalmars.com/webnews/newsgroups.php?article_id=88145).

Thanks for the ref. On one page linkies:

http://www.digitalmars.com/d/archives/digitalmars/D/Fully_dynamic_d_by_opDotExp_overloading_88145.html
http://www.digitalmars.com/d/archives/digitalmars/D/Re_Fully_dynamic_d_by_opDotExp_overloading_88270.html

Walter Bright:

> 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.

I see, you want a Swiss army knife language :o)

Before choosing a design I suggest to look at how both Java and C#4 have done it, few random links about C#4: http://msdn.microsoft.com/en-us/library/dd264736%28VS.100%29.aspx http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx http://geekswithblogs.net/sdorman/archive/2008/11/16/c-4.0-dynamic-programming.aspx

Similar links can be found for the invokedynamic of Java VM.

Bye,
bearophile

Walter Bright wrote:
> Simen kjaeraas wrote:
>> davidl implemented this as opDotExp in "Fully dynamic d by opDotExp overloading"
>> (http://www.digitalmars.com/webnews/newsgroups.php?article_id=88145).
> 
> Thanks for the ref. On one page linkies:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/Fully_dynamic_d_by_opDotExp_overloading_88145.html 
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/Re_Fully_dynamic_d_by_opDotExp_overloading_88270.html 
> 

And clearly, this idea was proposed before, including the templated version.

Walter Bright wrote:
> And clearly, this idea was proposed before, including the templated version.

I also see (reading it) that it was pretty thoroughly discussed. I'm convinced we should do it.

bearophile wrote:
> I see, you want a Swiss army knife language :o)
> 
> Before choosing a design I suggest to look at how both Java and C#4 have done it, few random links about C#4:
> http://msdn.microsoft.com/en-us/library/dd264736%28VS.100%29.aspx
> http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx
> http://geekswithblogs.net/sdorman/archive/2008/11/16/c-4.0-dynamic-programming.aspx

I think the D approach is superior, because it offers many more ways of doing things (it's implemented nearly completely as a library feature). C# was forced to do it with a magic type because it doesn't support templates.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> bearophile wrote:
> > I see, you want a Swiss army knife language :o)
> >
> > Before choosing a design I suggest to look at how both Java and C#4 have done
it, few random links about C#4:
> > http://msdn.microsoft.com/en-us/library/dd264736%28VS.100%29.aspx http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx
> >
http://geekswithblogs.net/sdorman/archive/2008/11/16/c-4.0-dynamic-programming.aspx
> I think the D approach is superior, because it offers many more ways of doing things (it's implemented nearly completely as a library feature). C# was forced to do it with a magic type because it doesn't support templates.

Sometimes I feel like there should be a law similar to Greenspun's Law for language design:

Any sufficiently long-lived language that promises to be "simpler" than C++ and D will grow to contain an ad-hoc, bug-ridden, informally specified, slow implementation of half of C++ and D.

dsimcha wrote:
> Sometimes I feel like there should be a law similar to Greenspun's Law for
> language design:
> 
> Any sufficiently long-lived language that promises to be "simpler" than C++ and D
> will grow to contain an ad-hoc, bug-ridden, informally specified, slow
> implementation of half of C++ and D.

The dogged inventiveness of the C++ community never ceases to amaze me. Someone always finds a way to make a library to support some paradigm. Look at all the things Boost does.

The problem, though, is the result is often just so strange I'd rather do without. Sometimes, you just need to improve the language to support things better.