dynamic classes and duck typing

[Bill Baxter]

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