On 10/16/2010 03:30 PM, Michel Fortin wrote:
On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
