dynamic classes and duck typing

[Pelle Månsson]

Bill Baxter wrote:
> 2009/12/1 Ary Borenszweig <ary at esperanto.org.ar>:
>> Denis Koroskin wrote:
>>> On Tue, 01 Dec 2009 15:47:43 +0300, Ary Borenszweig <ary at esperanto.org.ar>
>>> wrote:
>>>
>>>> Denis Koroskin wrote:
>>>>> On Tue, 01 Dec 2009 15:05:16 +0300, Ary Borenszweig
>>>>> <ary at esperanto.org.ar> wrote:
>>>>>
>>>>>> Ary Borenszweig wrote:
>>>>>>> retard wrote:
>>>>>>>> Tue, 01 Dec 2009 03:16:47 -0800, Walter Bright wrote:
>>>>>>>>
>>>>>>>>> Ary Borenszweig wrote:
>>>>>>>>>> Can you show examples of points 2, 3 and 4?
>>>>>>>>> Have opDispatch look up the string in an associative array that
>>>>>>>>> returns
>>>>>>>>> an associated delegate, then call the delegate.
>>>>>>>>>
>>>>>>>>> The dynamic part will be loading up the associative array at run
>>>>>>>>> time.
>>>>>>>> This is not exactly what everyone of us expected. I'd like to have
>>>>>>>> something like
>>>>>>>>
>>>>>>>> void foo(Object o) {
>>>>>>>> �o.duckMethod();
>>>>>>>> }
>>>>>>>>
>>>>>>>> foo(new Object() { void duckMethod() {} });
>>>>>>>>
>>>>>>>> The feature isn't very dynamic since the dispatch rules are defined
>>>>>>>> statically. The only thing you can do is rewire the associative array when
>>>>>>>> forwarding statically precalculated dispatching.
>>>>>>> �Exactly! That's the kind of example I was looking for, thanks.
>>>>>> Actuall, just the first part of the example:
>>>>>>
>>>>>> void foo(Object o) {
>>>>>> � �o.duckMethod();
>>>>>> }
>>>>>>
>>>>>> Can't do that because even if the real instance of Object has an
>>>>>> opDispatch method, it'll give a compile-time error because Object does not
>>>>>> defines duckMethod.
>>>>>>
>>>>>> That's why this is something useful in scripting languages (or ruby,
>>>>>> python, etc.): if the method is not defined at runtime it's an error unless
>>>>>> you define the magic function that catches all. Can't do that in D because
>>>>>> the lookup is done at runtime.
>>>>>>
>>>>>> Basically:
>>>>>>
>>>>>> Dynanic d = ...;
>>>>>> d.something(1, 2, 3);
>>>>>>
>>>>>> is just a shortcut for doing
>>>>>>
>>>>>> d.opDispatch!("something")(1, 2, 3);
>>>>>>
>>>>>> (and it's actually what the compiler does) but it's a standarized way
>>>>>> of doing that. What's the fun in that?
>>>>> �The fun is that you can call d.foo and d.bar() even though there is no
>>>>> such method/property.
>>>>> �In ActionScript (and JavaScript, too, I assume), foo.bar is
>>>>> auto-magically rewritten as foo["bar"]. What's fun in that?
>>>> The fun is that in Javascript I can do:
>>>>
>>>> ---
>>>> function yourMagicFunction(d) {
>>>> � d.foo();
>>>> }
>>>>
>>>> var something = fromSomewhere();
>>>> yourMagicFunction(something);
>>>> ---
>>>>
>>>> and it'll work in Javascript because there's no type-checking at
>>>> compile-time (well, because there's no compile-time :P)
>>>>
>>>> Let's translate this to D:
>>>>
>>>> ---
>>>> void yourMagicFunction(WhatTypeToPutHere d) {
>>>> � d.foo();
>>>> }
>>>>
>>>> auto something = fromSomewhere();
>>>> yourMagicFunction(something);
>>>> ---
>>>>
>>> I believe there will soon be a library type that would allow that.
>> It's called a template:
>>
>> void yourMagicFunction(T)(T d) {
>> �d.foo();
>> }
>>
>> I can write that and I can always compile my code. I can use that function
>> with any kind of symbol as long as it defines foo, whether it's by
>> definining it explicitly, in it's hierarchy, in an aliased this symbol or in
>> an opDispatch. That's the same concept as any function in Javascript (except
>> that in Javascript if the argument doesn't define foo it's a runtime error
>> and in D it'll be a compile-time error).
> 
> If you define a catch-all opDispatch that forwards to a method that
> does dynamic lookup, then the error will be a runtime error.
> 
> --bb
Which is correct, awesome, great, etc. Wouldn't want it any other way!