On Sunday, September 29, 2002, at 05:11 PM, Michael G Schwern wrote: > Here's some open problems: > > Would this be the default behavior for overridden methods, or will the > parent class/methods have to be declared "is interface" for the > signatures > to be enforced on subclasses?
Heck, I'll jump into this one, since I've been working in _way_ too many OO variations lately, some of them inflicted upon myself. While I hope perl6 will allow extendable OO methodologies, the out-of-box one needs to be as robust as possible. Here's a strawman opinion we can argue against: I originally thought I was going to argue that it should be the default behavior (to avoid yet more cruft in the method prototype) but thinking about it more, I'll make the case that yes, you should have to say "is interface", if that's what you mean. The reason being "private" methods; while the interfaces to an object must remain consistent, I don't think we should enforce the same rigor on internal methods of a class. There are cases where you want something like: method do_internal_initialization ($num) { ... } but you don't care if you stomp on it's name for certain subclasses that need similar private methods: method do_internal_initialization ($hashref) { ... } (...leading to an additional question, will there be a way to specify methods of a class that are *not* inherited by subclasses?) So I'd say we either need "is interface", or (worse) "is not interface". > Will interfaces be ignorable? .... and if we _do_ say any of the above, then they are not ignorable, on pain o' death. I'd argue there shouldn't be any way around it, period, or we lose the whole point of the implied consistency. Can anyone think of a counterexample? > What if a subclass adds extra, optional arguments to a method, is that > ok? This is the scariest question, I think... In theory, yes, there are lots of potential interfaces that would benefit from optional extensions, & I've made a few. In strict terms, though, they violate the whole idea of "common, invariant interface", so I never know if what I've done is Acceptable, or a Shameful Hack... anyone care to make a case either way on this one? > What about the return type? If you're doing strict OO it would be > nice to > specify the signature of the return value as well, which will get > interesting to be able to describe totally the various ways in which a > method can return in different contexts. While I cannot conceive what monstrosity of syntax we could put in the method prototype to say "I want to return this type in this context, and this type in this context, etc., etc.", I would argue that specifying it is an absolute necessity; a fundamental part of an Interface is the type of information it returns: we have to define it as part of the Interface (including all recognized contexts), or we set ourselves up such that different subclasses may return their information differently. Better to enforce it? (Of course, if our interface "a" is returning an object, of a class that flattens itself differently in different contexts, then do we say the interface can only return object classes derived from that first object class? And do we restrict the possible "flattenings" of the object class itself, using an interface, so subclasses of the returned obj can't muck with it and unintentionally violate our first interface ("a")?... there's a can of worms, boy...) Mike Lazzaro Cognitivity (http://www.cognitivity.com/)