Re: Interfaces
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/)
Re: Passing arguments
On Sun, Sep 29, 2002 at 09:31:46PM -, Smylers wrote:
> Consider this Perl 5:
>
> while (<>)
> {
> # ...
> foreach my $fruit (qw)
> {
> # ...
> }
> }
>
> Inside the inner loop C<$_> still holds the current line. In the
> equivalent Perl 6 syntax, insider the inner loop C<$_> will be an alias
> of C<$fruit> and there wouldn't be any way of getting the current line.
Well, there's always $OUTER::_ and $OUTER::OUTER::_ etc if you _really_
need them.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Interfaces
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]>
Re: Interfaces
[EMAIL PROTECTED] (Michael G Schwern) writes:
> method _do_internal_init ($num) is private {
Just thinking aloud, would
sub foo is method is private is integer is fungible {
be better written as
sub foo is fungible private integer method {
or not?
--
Those who do not understand Unix are condemned to reinvent it, poorly.
- Henry Spencer, University of Toronto Unix hack
RE: Interfaces
Michael Lazzaro wrote: > > 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? 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.) On a slightly different note, if we have interfaces then I'd really like to follow the Eiffel model: features such as renaming methods in the derived class may seem a bit strange; but they can be useful if you have have name-conflicts with multiple inheritance. Oh yes, and we need to make sure DBC stuff is part of the interface, not the implementation. Dave.
Interface lists (was Re: Interfaces)
On Tue, Oct 01, 2002 at 01:36:19AM +0100, Simon Cozens wrote:
> [EMAIL PROTECTED] (Michael G Schwern) writes:
> > method _do_internal_init ($num) is private {
>
> Just thinking aloud, would
> sub foo is method is private is integer is fungible {
>
> be better written as
> sub foo is fungible private integer method {
>
> or not?
How about seperated by commas, like any other list?
method foo is fungible, private, integer {
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
"That's what Jagulars always do," said Pooh, much interested. "They call
'Help! Help!' and then when you look up they drop down on you."
Re: Interfaces
On Mon, Sep 30, 2002 at 06:04:28PM -0700, David Whipp wrote: > On a slightly different note, if we have interfaces then I'd really > like to follow the Eiffel model: features such as renaming methods > in the derived class may seem a bit strange; but they can be useful > if you have have name-conflicts with multiple inheritance. I'm not familiar with the Eiffel beyond "it's the DBC language and it's French", but wouldn't this simply be covered by aliasing? Which I guess raises the question, is a method's signature and attributes part of the method itself, or it's name? In other words, do aliases to the same method carry the same signature and attributes? > Oh yes, and we need to make sure DBC stuff is part of the interface, not > the implementation. Sensible. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Playstation? Of course Perl runs on Playstation. -- Jarkko Hietaniemi
Subject-Oriented Programming
Last year at JAOO I stumbled on this thing called Subject-Oriented Programming which looked interesting. I dug up some papers on the subject and tried to make an implementation but found I really didn't properly understand it and the papers were too bogged down in C++ implementation details to really describe it well. So since this list is a magnet for folks who know obscure programming techniques, is there anyone out there familiar enough with SOP that they could lay out some examples in pseudo-perl? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Stupid am I? Stupid like a fox!
Re: Interface lists (was Re: Interfaces)
On Mon, Sep 30, 2002 at 11:16:20PM -0400, Michael G Schwern wrote:
> How about seperated by commas, like any other list?
>
> method foo is fungible, private, integer {
Well, if we're going to use a /list/, how about
method foo ($param) ^is (fungible, private, integer) {
?
:) 1/2
