On 10/17/2010 01:54 AM, lurker wrote:
Andrei Alexandrescu Wrote:
I was talking to Walter about Kenji's adaptTo. We both think it's a
very powerful enabler, but adaptTo is a bland name. After
discussing a few marketing strategies, I proposed "duck". It's
short, simple, and evokes "duck typing".
class C { int draw(){ return 10; } } interface Drawable { long
draw(); } ... auto c = new C; auto d = duck!Drawable(c);
Object c = new C; auto d = duck!Drawable(c); // awes
does this work? After all, c is a C:
Object c = new C; auto d = duck!Drawable(cast(C)c);
One fears this feature has little real world use. But it's a great
way to add additional bloat to the puny little Phobos...
It's amusing as always that the syntax is being discussed before we
even know how this works. How does the int -> long coercion work
there? Any possibility to get a written spec for this?
Fair point, but the discussion started as simply naming a
well-understood artifact. That was Kenji Hara's code here:
http://github.com/9rnsr/scrap/blob/master/interfaces/interfaces.d
Essentially what his function did was to offer a given interface on top
of an object (that did not implement the interface). The mechanism for
doing so was to generate simple forwarding functions.
From there, the discussion sprawled into defining different similar
functions, i.e. one that implements a given interface for a given object
on a best-effort basis and throws for non-matched methods.
Discussion also extended into a completely dynamic facility that
promises any method and uses runtime reflection (and exceptions) to
implement dynamic typing. It has been rightly pointed out that Variant
is the best type for that.
Once such functions will be integrated into Phobos, they will be
properly documented. I think it's okay to keep the discussion loosely
structured for now.
Andrei
