On Monday, September 30, 2002, at 05:23 PM, Michael G Schwern wrote:
> 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.
I guess what bothers me is the loophole issue, sort of... in specific,
who gets to decide whether a given interface method is optional. I'm
hoping that the optional-ness of an interface is itself optional. And
that the optional-ness of a non-optional interface is not optional. :-)
The problems arise anywhere you're referring to interface methods from
outside the class. It may be perfectly OK for a subclass of a given
class to reuse an interface method for a different purpose, etc., so
long as nothing outside the inheritance chain is using it... but I'd
very much like a way for an interface to say "don't muck with me", so
that sensitive interfaces can be guaranteed as forever invariant, if
you really, really mean it.
My hope is that you could define the "non-overridability" of a given
interface method in the parent class, to guarantee enforcement among
subclasses. Possible pseudocode choices include:
# (1) explicitly not an interface method
method foo (...) is private { ... }
# (2) explicitly an interface method
method foo (...) is interface { ... }
# (3) explicitly a "strict" interface, can't change it in subclasses
method foo (...) is strict interface { ... }
# (4) explicitly "optional", subclasses can muck with it
method foo (...) is optional interface { ... }
# (5) So what's the unattributed case? An implied interface,
# implied optional interface, or just explicitly not private?
method foo (...) { ... }
I'd say if we had (1), and if (2) enforced "strict", then (5) could
mean "optional, not private, but not strictly an interface either...",
and we wouldn't need the icky (3) or (4) at all. That would go nicely
with expectations, I think. (But are there other possibilities besides
"private" and "interface", e.g. "protected", etc.?)
On Monday, September 30, 2002, at 06:04 PM, David Whipp wrote:
>>> What if a subclass adds extra, optional arguments to a
>>> method, is that ok?
>>
>> ... In theory, yes...
>
> 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?)
>> 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")?...
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, and therefore could be expressible in
the same syntax as other interfaces, with the same issues of
(non)strictness. (And for that matter, the contextual return values of
any arbitrary function, foo(), can be expressed as an interface to a
one-off class named "foo", which implies large commonalities of
syntax/implementation between classes, methods, operators, and ordinary
functions [1]... hee hee...)
Mike Lazzaro
Cognitivity (http://www.cognitivity.com/)
[1] ...which implies that all Perl6 operators and functions can (must?)
be implemented as flyweight classes with interfaces that define their
properties/attributes/arguments/contexts, but that's a Perl6 <-->
Parrot thing.
