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/)
