duck!

kenji hara k.hara.pg at gmail.com
Sat Oct 16 15:57:22 PDT 2010


Current dmd does not enough support runtime reflection.

----
// test code
class A
{
    int quack() { return 10; }
}

void main()
{
    Object o = new A();
    TypeInfo ti;

    ti = typeid(o);
    if( auto ti_c = cast(TypeInfo_Class)ti ){

        auto members = ti_c.getMembers("quack");
        assert(members !is null);   // --> failed!!

        foreach( mi; members ){
            if( auto mi_fn = cast(MemberInfo_function)mi ){
                assert(mi_fn.name == "quack");
                auto fp = mi_fn.fp;
                auto ti_fn = mi_fn.typeInfo;
                //...
            }
        }
    }
}
----

Kenji Hara.

2010/10/17 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
> On 10/16/2010 03:30 PM, Michel Fortin wrote:
>>
>> On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> On 10/16/2010 02:54 PM, kenji hara wrote:
>>>>
>>>> Adapter-Pattern! I'd have forgotten the name.
>>>> It is NOT equals to duck-typing.
>>>
>>> It's a subset of duck typing. I don't think calling a function that
>>> supports a limited form of duck typing "duck" is a lie.
>>
>> Not a lie, just a word with a deceptive meaning that'll lead people to
>> believe something else than the truth. Some cynically call that
>> marketing speech.
>
> As Walter said, that's probably why he, you, and myself aren't marketers.
>
>> In my opinion, a duck type in D should be a variant that allows you to
>> call all the functions of the underlying object, and throws (at runtime)
>> when no matching function is found. I think you'll agree with me that
>> this is very far from the adapter pattern.
>
> In fact I had this idea while running:
>
> interface Widget
> {
>    void draw();
>    void move(int x, int y);
> }
>
> interface ColoredWidget : Widget
> {
>   void setColor(Color c);
> }
>
> class Drawable
> {
>   void draw();
>   void move(int x, int y);
> }
>
> unittest
> {
>    auto x = new Drawable;
>    auto a = nameone!Widget(x); // works
>    //auto b = nameone!ColoredWidget(x); // doesn't compile
>    auto c = nametwo!ColoredWidget(x);
>    c.draw(); // works
>    c.setColor(red); // throws NotImplemented during runtime
> }
>
> "nameone" implements Kenji's current code. "nametwo" is the looser form of
> duck typing: whatever methods match will work, and the rest are implemented
> to throw during runtime.
>
> Question is, of course, figuring out good substitutes for nameone and
> nametwo.
>
> Kenji, do you think you could also implement nametwo?
>
>
> Andrei
>


More information about the Digitalmars-d mailing list