On Mon, Sep 30, 2002 at 10:12:48AM -0700, Michael Lazzaro wrote:
> 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.
Internal methods would simply be declared private and not be inherited, so
its not a problem.
method _do_internal_init ($num) is private {
...
}
Last I heard, Perl 6 will have basic privacy enforcement, something like the
above.
> >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?
If I inherit from some parent which is well designed except for one really
poorly designed method.
Or maybe the parent class uses a really good name for a really silly
purpose, and I want that name back.
Or maybe I do want to deliberately have a subclass which is different than
the parent.
Or maybe the parent accidentally inherits something, perhaps via multiple
inheritence, and now I'm suck with it.
Not all subclasses are simply functional extensions of the parent. In these
cases I should have a way to get around the interface restriction, probably
as an attribute to the overriding method.
OTOH, Java interfaces have a loophole which is considered a design mistake.
An interface can declare some parts of the interface optional and then
implementors can decide if they want to implement it or not. The upshot
being that if you use a subclass in Java you can't rely on the optional
parts being there.
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.
> >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?
The child's interface still supports the complete interface of the parent,
so I don't see it as a problem. Sure beats having to write a whole new set
of method names just because you want to add an extra argument on the end.
> >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."
To paraphrase Damian at YAPC::Europe, "It's Damian's problem." ;)
> 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?
Yes. The object class is simply a return type.
> 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...)
At that point you want to use the Design By Contract features, probably via
a class invariant, to ensure that all your subclasses flatten the same way.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
"In my day, we didn't have none of yer new-fangled token-pasting
operators! We stuck the tokens together with our BARE HANDS and we
LIKED IT."
-- Mark-Jason Dominus fondly remembers perl 1.0
in <[EMAIL PROTECTED]>
