On Tue, Oct 01, 2002 at 11:51:02AM -0700, Michael Lazzaro wrote: > >This comes down to an OO philosophy issue. If Perl 6 wants a strict OO > >style, don't put in a loophole. If they want to leave some room to > >play, > >put in the ability to turn some of the strictness off. > > I guess what bothers me is the loophole issue, sort of... in specific, > who gets to decide whether a given interface method is optional.
If we do it loosely, the subclasser decides if they want to follow the interface, since most violations of an interface are done because it's being used in an unforseen manner. But they have to explicitly say they're violating it. I can't see any good reason why an interface author would want to make their interface optional. If we do it strictly, interfaces are not optional. Perhaps a way to sharpen the focus on this is to expand the discusson of strictness to include not just method prototypes but Design-By-Contract features as well (pre and post conditions and invariants). Should DBC conditions be overridable? Since it's not terribly useful to override a signature only to be stopped by a pre-condition. Taken as a whole, I'm leaning towards no. Interfaces and conditions should be strict. They can be gotten around using delegation, which should be built into Perl 6 anyway. > >I don't think that the addition of an optional parameter > >violates any substitution principle: users of the base-class > >interface couldn't use the extra params (because they're not in > >the interface); but a user of the derived-class's interface > >can use the extra power (because they are in that interface). > >A derived class is always allowed to add things (thus, you can > >weaken preconditions, stengthen postconditions, add extra > >methods, return a more specific result, ...; but you can't > >strengthen a precondtion, nor weaken a postcondition, etc.) > > Agreed. If we had some concept like "strict" vs. "overridable" > interfaces, should "strict" prevent this, too, or are extra, optional > parameters always allowed as a special case (under the assumption that > they can't hurt anything that doesn't know about them?) Unless someone can come up with a practical case of adding parameters which violates the interface, I'd say there's no problem, strict or no strict. > My musing is that the behavior of a class in different contexts is > itself an interface, in the sense of being a contract between a > class/subclass and it's users Ah HA! Contract! Return values can be enforce via a simple DBC post condition, no need to invent a whole new return value signature. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One And if you don't know Which To Do Of all the things in front of you, Then what you'll have when you are through Is just a mess without a clue. Of all the best that can come true If you know What and Which and Who.
