November 27, 2009 dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
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.) |
November 27, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
November 27, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen kjaeraas | 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 |
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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.
|
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | == 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. |
November 28, 2009 Re: dynamic classes and duck typing | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | 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.
|
Copyright © 1999-2021 by the D Language Foundation