On Jul 24, chromatic wrote:
On Thursday, July 24, 2003, at 05:28 PM, Benjamin Goldberg wrote:
The problem with Java interfaces is that you have to rely on the library writer to have expected you to use an interface. Given the amount of CPAN modules that, for example, expect a glob and preclude me from passing in an IO::Handle with code like this:
croak "Need a glob" unless ref $thingie eq 'GLOB';
I'm not sure that the Java style is helpful. I'd rather not multiply entities needlessly.
My two cents: the best possible use of an interface/protocol is to define a set of methods *and their semantics*, and *not* their implementation. In pseudocode:
protocol Window { method print; method close; method bringToFront; }
class MyWindow: implements Window;
You're saying that MyWindow has print, close, and bringToFront methods. You're not saying whether they're inherited, or implemented from scratch. You *are* saying that close() will erase a graphical rectangle on a display, not disconnect a filehandle or return "true" if it's nearby.
So the useful feature of this abstraction is that, given an anonymous object, you don't ask, "do you implement method called so-and-so", e.g., "$anon->can('print')"; you ask it, "do you do the things that a Window does," e.g., "$anon->implements('Window')".
So a class shouldn't inherit from an interface. It should assert that it implements it.
Totally on track. I'd like to also rehash what Mr. Goldberg was getting at:
One of the very useful feature of Objective C's protocols is that they be used with classes which did not originally declare implementation of the protocol: Say a library module from CPAN implements half of the functionality you want. You want to embed the rest in a new class of your devising, but it doesn't have an isa-relationship to the CPAN module. You can simply apply a protocol to the problem, and still wind up with a typesafe solution. Even if you tried to patch your protocol into the CPAN module, the patch probably wouldn't be applied because your app and its protocol are meaningless in a broader context. I'm going to hijack somebody else's meme here: This dynamism enables accidental polymorphism--it lets implicit method patterns surface into explicit protocols without requiring changes to existing code, and so empowers the caller over the tyranny of the library author: An element of object-oriented design can arise after the implementation of a class. That has a very Perl 6-ish feel to it, closer to the untyped flexibility of Perl 5 than the de rigueur rigidity of Java.
—
Gordon Henriksen [EMAIL PROTECTED]
