In sean’s case, class and/or module were sufficient to define
interface. […] He goes on to say the same re: inheritance
and module inclusion.
To be fair, he goes beyond class/module model. The reason we tend to object
to the class/module model of interfaces is that things like StringIO, which
has no module or inheritance relationship with IO, tends to be used in
places where an IO object is expected.
But Sean also proposes an interface command that can be used to indicate
non-class/non-module conformance. You can say …
class StringIO
interface IO
end
The interface command adds IO to a list of supported interfaces for the
StringIO class. It gets no implementation from IO, nor does it inherit from
IO. The interface command is just there so that any conformance testing on
a StringIO object can say “Oh look. This object claims to be able to do
whatever an IO object would do”.
This decouples conformance from mere class inheritance/module inclusion,
although class inheritance and module inclusion still count as conformance.
I haven’t decided whether I like this or not. Right now I’m kinda neutral.
It avoids the problem of decreased flexibility at the cost of an extra line
of code.
···
–
– Jim (still thinking about it) Weirich
