Private contracts?
I've been mucking about a bit more with this whole interface thing.
So if we make method signatures only enforced on subclasses if the parent
class or method has the interface property...
except private methods, obviously.
And if we make pre/post conditions and class invariants always enforced...
shouldn't we have private invariants and conditions?
class Car is interface {
attr wheels;
invar { .wheels == 4 }
method accel($how_fast);
method turn($direction, $how_sharp);
}
class ATV is Car, interface {
attr _tilt is private;
invar { ._tilt = 20 } is private;
method turn($direction, $how_sharp) {
pre { $how_sharp = 20 } is private;
...implementation...
}
}
I've implemented an ATV where I've put in a saftey protection against
rolling over in a turn as both an invariant and a pre-condition. It will
not allow you to turn the car too sharply, else it simply blows up. Wait
second... ;)
But I don't want my subclasses to be constrained by that. It's just an
implementation detail that I only wish to enforce upon ATV and not it's
children. So they're private.
Makes sense, no?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Remember, any tool can be the right tool.
-- Red Green
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote:
class ATV is Car, interface {
Hmmm. That should probably be
class ATV isa Car is interface {
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Help, help! A Heffalump, a Horrible Heffalump! Help, help, a Herrible
Hoffalump! Hoff, Hoff, a Hellible Horralump!
Re: Private contracts?
I've been mucking about a bit more with this whole interface thing. So if we make method signatures only enforced on subclasses if the parent class or method has the interface property... except private methods, obviously. And if we make pre/post conditions and class invariants always enforced... shouldn't we have private invariants and conditions? Semi-tangential to the point of your message... With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. The postcondition is not really a problem since one can always add additional checks. However, if the parent's preconditions apply to the child invariably, it would be rather difficult to make your subclass accept a wider variety of input. I'm not proposing a solution, but rather just a problem to keep in mind. Mike Lambert
Re: Private contracts?
On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote:
On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote:
class ATV is Car, interface {
Hmmm. That should probably be
class ATV isa Car is interface {
That's:
class ATV is Car is interface {
We haven't finally decided how properties will be defined. They may be
subs:
sub *PropertyName is property ($referent, $data) {...}
they may be methods:
method PropertyName is property ($self: $data) {...}
they may be classes:
class PropertyName is Property {...}
# or, like grammar definitions
property PropertyName {...}
or they may be some variation on these or something else entirely.
However they're defined, they will be clearly marked internally as
properties, so there's little risk of confusing property attachment with
inheritance.
Allison
Re: Private contracts?
On Thu, Oct 03, 2002 at 03:45:33PM -0500, Allison Randal wrote:
On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote:
On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote:
class ATV is Car, interface {
Hmmm. That should probably be
class ATV isa Car is interface {
That's:
class ATV is Car is interface {
Wouldn't this mean that class names and property names will inevitably
clash, so you can't have a class and a property with the same name?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
The key, my friend, is hash browns.
http://www.goats.com/archive/980402.html
Re: Private contracts?
On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. How exactly does one weaken a precondition? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Home of da bomb
Re: Private contracts?
Makes sense, no?
I like that quite a lot.
One question I still have is the syntax of pre/post conditions, e.g:
method turn($direction, $how_sharp) {
pre { $how_sharp = 20 } is private;
...implementation...
}
This is obviously how it would fall out from Apocalypse 4, pre/post
being basically types of exception, but I keep having nagging concerns
about it. To me, this keeps looking like pre { ... } is a
precondition attached to the _implementation_ of the given method, not
the _signature_ of a given method... For the is private case above,
it doesn't make much difference, but I keep thinking something like the
below just feels wonky (?)...
class Vehicle is interface {
attr $tilt;
attr $min_sharpness;
method turn($direction, $how_sharp) {
pre { $how_sharp = $self.min_sharpness }
... a default implementation, if desired ...
}
}
class Car is Vehicle {
method turn { # this calls the precondition
...
$self.SUPER.turn( ... );# ... hopefully not
twice? ...
... a derived implementation ...
}
}
class Cycle is Vehicle {
method turn { # does this call the
precondition? YES?
... a completely alternative implementation that doesn't call
super
}
}
Do you think it's sufficiently clear to newbies that the pre { } is
associated with the signature of the turn() interface method, and not
just the _implementation_ of turn() in Vehicle? e.g. I want a
precondition associated with turn() that is called for _all_
subclasses, whether they call the superclass implementation of turn()
or not, is it clear that that's going on? _IS_ it going on, in the
above?
On Thursday, October 3, 2002, at 01:11 PM, Allison Randal wrote:
BTW, that's:
attr $.tilt;
Attributes are private by default.
(As a lame aside, are we going to have a concept of private vs.
protected vs. public, or just private/public? (In other words,
does private permit access by subclasses?) Not recommending it, just
wondering if anyone thinks we need it.)
MikeL
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. How exactly does one weaken a precondition? You weaken a precondition by adding ORs; you strengthen a postcondition by adding ANDs. Trey
Re: Private contracts?
On Thu, Oct 03, 2002 at 05:14:22PM -0400, Michael G Schwern wrote:
On Thu, Oct 03, 2002 at 03:45:33PM -0500, Allison Randal wrote:
On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote:
On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote:
class ATV is Car, interface {
Hmmm. That should probably be
class ATV isa Car is interface {
That's:
class ATV is Car is interface {
Wouldn't this mean that class names and property names will inevitably
clash, so you can't have a class and a property with the same name?
Yes. But if properties are classes (the generally favored solution, at
least until Zurich), that's to be expected.
So far, classes are uppercase and properties are lowercase, but that's
convention, not law.
Allison
RE: Private contracts?
Michael G Schwern:
I've been mucking about a bit more with this whole interface thing.
So if we make method signatures only enforced on subclasses
if the parent class or method has the interface property...
except private methods, obviously.
And if we make pre/post conditions and class invariants
always enforced...
no.
post-conditions and invariants are always enforced, but pre-conditions are
different. A derived interface can loosen input constraints... so it must be
able to either satisfy all inherited pre-conditions _or_ its own
pre-conditions.
shouldn't we have private invariants and conditions?
no.
I should inject that I disagree with the use of term private as meaning
non-inheritable. I think of private as an methods and attributes accessible
only within the namespace of that class or its descendants. Perhaps a better
term would be something like:
method foo is disinherited { ... }
I also need to separate out the DBC topic from the interface one. For
instance I have a hard time thinking about attributes in the context of
interfaces. For me, interfaces should be limited to a bunch of abstract
methods with conditions. Any other declarations within an interface IMO
should be errors. I.e., all other declarations belong in the implementation
class...
If you want to have a public and private inheritable interfaces that's
fine. But what's the point of a non-inheritable interface? Myself, I call
non-inheritable methods functions.
class ATV is Car, interface {
attr _tilt is private;
invar { ._tilt = 20 } is private;
method turn($direction, $how_sharp) {
pre { $how_sharp = 20 } is private;
...implementation...
}
}
An interface shouldn't have attributes. And per above, private
pre-conditions are pointless. I would rewrite the above as:
class ATV is Car, interface {
invar { .tilt = 20 };
method tilt() is private; # in the to class heirachy sense
method turn($direction, $how_sharp) {
pre { $how_sharp = 20 };
}
}
I've implemented an ATV where I've put in a saftey
protection against rolling over in a turn as both an
invariant and a pre-condition. It will not allow you
to turn the car too sharply, else it simply blows up.
Wait second... ;)
But I don't want my subclasses to be constrained by that.
It's just an implementation detail that I only wish to
enforce upon ATV and not it's children. So they're
private.
Makes sense, no?
No. Per DBC, pre-conditions are satisfied if either the inherited
pre-conditions _or_ its own pre-conditions are satisfied. Thus allowing the
loosening of input constraints which I believe is what you're after.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, Allison Randal writes: So far, classes are uppercase and properties are lowercase, but that's convention, not law. Do runtime (value) properties and compile-time (variable) properties share the same namespace? That is, to go back to an earlier discussion, if there is a system-defined value property Ctrue which marks a value as true in boolean contexts, can I also define a compile-time property Ctrue that makes the variable evaluate as true, whatever its value? Trey
RE: Private contracts?
Garrett Goebel: Michael G Schwern: But I don't want my subclasses to be constrained by that. It's just an implementation detail that I only wish to enforce upon ATV and not it's children. implementation details don't belong in interfaces
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:29:57PM -0700, Michael Lazzaro wrote: (As a lame aside, are we going to have a concept of private vs. protected vs. public, or just private/public? No protected. Even Stroustrup admits it was a mistake in DE. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:29:57PM -0700, Michael Lazzaro wrote:
One question I still have is the syntax of pre/post conditions, e.g:
method turn($direction, $how_sharp) {
pre { $how_sharp = 20 } is private;
...implementation...
}
This is obviously how it would fall out from Apocalypse 4, pre/post
being basically types of exception, but I keep having nagging concerns
about it. To me, this keeps looking like pre { ... } is a
precondition attached to the _implementation_ of the given method, not
the _signature_ of a given method...
I don't know, but I think it's supposed to be like this:
# part of the signature
method turn($dir,$ang) is pre { $ang = 20 } {
...
}
# part of the implementation
method turn($dir,$ang) {
PRE { $ang = 20 }
...
}
turn() methods of derived classes would inherit the precondition in the
first case but not the second. I don't know why you'd want to do this
exactly, but it seems to me that perl should allow it.
On Thursday, October 3, 2002, at 01:11 PM, Allison Randal wrote:
BTW, that's:
attr $.tilt;
Attributes are private by default.
(As a lame aside, are we going to have a concept of private vs.
protected vs. public, or just private/public? (In other words,
does private permit access by subclasses?) Not recommending it, just
wondering if anyone thinks we need it.)
I don't think we should be actively reproducing C++'s mistakes :-)
With the constructs shown so far, I can guess that it should be
possible for someone to implement protected if they wanted it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Private contracts?
On Thu, Oct 03, 2002 at 04:54:13PM -0500, Garrett Goebel wrote: Garrett Goebel: Michael G Schwern: But I don't want my subclasses to be constrained by that. It's just an implementation detail that I only wish to enforce upon ATV and not it's children. implementation details don't belong in interfaces It's encoded as a private condition, so it's not part of the interface. I see class invariants and conditions as just powerful, well organized assertions, so naturally I'm going to want to use them for more than just specifying an interface contract. In this case, I'm using them to ensure that internal details of my implementation are kept in order. It would be silly to have to define a whole new syntax for that purpose, so I just make them private. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One The eye opening delightful morning taste of expired cheese bits in sour milk!
Re: Private contracts?
On Thu, Oct 03, 2002 at 05:23:08PM -0500, Jonathan Scott Duff wrote:
I don't know, but I think it's supposed to be like this:
# part of the signature
method turn($dir,$ang) is pre { $ang = 20 } {
...
}
# part of the implementation
method turn($dir,$ang) {
PRE { $ang = 20 }
...
}
turn() methods of derived classes would inherit the precondition in the
first case but not the second. I don't know why you'd want to do this
exactly, but it seems to me that perl should allow it.
I see us already smashing too many things into the method signature as it
is. It will rapidly get messy if you have a method with a complex signature
and a handful of attributes and preconditions.
Also, where do the postconditions go? In the signature at the front? That
doesn't make sense, it should go at the end so you can keep them in mind
when you're writing the return code.
Consider...
method foo($this, $that) is memoized is something
is pre { $this = 42 }
is pre { $that == $this / 2 }
is pre { a lot of code which is hard to
shove into a block of code
this close to the right margin }
is post { what is a post condition
doing at the front? }
{
...
}
They can, of course, be pulled back from the margin:
method foo($this, $that) is memoized is something
is pre { $this = 42 }
is pre { $that == $this / 2 }
is pre { now we have a little bit more room to play with using
a differnt indentation style }
is post { but post conditions are still distanced from the
code which return()s }
{
...
}
I realize that conditions are technically part of the signature, but putting
them in there paints us into a stylistic corner.
I'm also not fond of the pre/PRE distinction. Few of the other special
blocks (given, eval, try, invar, etc...) use all cap names. At least I hope
not. Simply attaching an is private attribute to a pre condition block
seems the simplest way to go about it. Just like any other private thing,
it's not inherited and not visible outside the current class. pre vs
PRE doesn't convey that meaning.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
AY! The ground beef, she is burning my groin!
http://sluggy.com/d/990105.html
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:29:57PM -0700, Michael Lazzaro wrote:
Do you think it's sufficiently clear to newbies that the pre { } is
associated with the signature of the turn() interface method, and not
just the _implementation_ of turn() in Vehicle?
The rule would be pretty simple to teach and remember, conditions and
invariants are inherited unless made private.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
It's Flypaper Licking time!
Re: Private contracts?
On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote: In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. How exactly does one weaken a precondition? You weaken a precondition by adding ORs; you strengthen a postcondition by adding ANDs. As expressions in Perl run a tad beyond simple boolean logic, could you give a concrete example? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One My beverage utensil experiences a volume crisis.
Delegation syntax? (was: Re: Private contracts)
On Thursday, October 3, 2002, at 03:18 PM, Paul Johnson wrote:
(As a lame aside, are we going to have a concept of private vs.
protected vs. public, or just private/public?
No protected. Even Stroustrup admits it was a mistake in DE.
Oh, thank God. I was hoping people would say that.
OK, for an entirely different thread...
Is there an accepted preliminary syntax for OO delegation? (I've
looked and can't find anything definitive.) By delegation, I mean
two different things (you can tell OO programming has firmly arrived by
the fact that, Babel-like, no group of people can ever agree on the
meaning of any given term, making all conversations painful).
1) Delegation through inheritance:
(a.k.a. mixin classes, hard delegation, concrete interfaces,
etc., etc.)
Example: I want to say that a class DataManager has the capabilities
of the interfaces DataStrategy and CacheStrategy, but is not strictly a
subclass of either. In other languages, this might appear like:
class DataManager implements DataStrategy, CacheStrategy { ... }
- or -
class DataManager mixin DataStrategy, CacheStrategy { ... }
(yes, I know you probably wouldn't do a Manager/Strategy like that.
it's just an example, and my mind is blanking right now...)
2) Delegation through attribute:
(a.k.a soft delegation, instance-based delegation, etc., etc.)
The ability to specify that, if an instance of an object DataSnippet
is affiliated with a specific, runtime instance of a DataManager, e.g.
class DataSnippet {
attr $data_manager is DataManager;
}
... then [some, all] public methods of $self.data_manager can
automatically be delegated by the DataSnippet to that specific
instance, eliminating the need for code that makes you want
to kill yourself:
method foo (...) { $self.data_manager.foo( ... ) }
method bar (...) { $self.data_manager.bar( ... ) }
# ... repeat until carpel tunnel syndrome sets in ...
I have no *good* syntax proposals for this, I don't think I've ever
seen the problem solved with syntax that I really ever liked.
MikeL
RE: Private contracts?
Michael G Schwern: On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote: In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. How exactly does one weaken a precondition? You weaken a precondition by adding ORs; you strengthen a postcondition by adding ANDs. As expressions in Perl run a tad beyond simple boolean logic, could you give a concrete example? all inherited pre-conditions pass or class' own pre-conditions pass -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Private contracts?
On Thu, Oct 03, 2002 at 04:47:26PM -0500, Garrett Goebel wrote:
And if we make pre/post conditions and class invariants
always enforced...
no.
post-conditions and invariants are always enforced, but pre-conditions are
different.
Right, right.
A derived interface can loosen input constraints... so it must be
able to either satisfy all inherited pre-conditions _or_ its own
pre-conditions.
Looking around, this seems to be regarded as something of a compromise
because truly determining what a real logical weaking is is hard. Are there
other ways to do it, just to mull them over?
shouldn't we have private invariants and conditions?
no.
Ummm, why?
I should inject that I disagree with the use of term private as meaning
non-inheritable. I think of private as an methods and attributes accessible
only within the namespace of that class or its descendants.
Isn't that protected?
As I understand it, Perl 6's private will be non-inheritable methods
accessable only inside the class which defined it. Ruby does it this way,
AFAIK.
Perhaps a better
term would be something like:
method foo is disinherited { ... }
is disowned
is get_a_haircut_and_a_job
is i_have_no_son
;)
I also need to separate out the DBC topic from the interface one. For
instance I have a hard time thinking about attributes in the context of
interfaces. For me, interfaces should be limited to a bunch of abstract
methods with conditions. Any other declarations within an interface IMO
should be errors. I.e., all other declarations belong in the implementation
class...
I hope we're not going to explicitly seperate interfaces from
implementation. ie. That you can define an interface at the same time as
you implement it. This is something I really like about Perl as opposed
to other OO systems, class definition and implementation are not kept
seperate.
class Human is interface {
attr head, shoulders, knees, toes;
invar { .head == 1 }
invar { .shoulders == 2 }
invar { .knees == 2 }
invar { .toes == 10 }
method talk ($say,$how_loud) {
$say.uc if $how_loud = 10:
print $say\n;
}
}
Of course, if interfaces in the Java sense are just classes with no
implementation details, there's no reason why you can't do it seperately.
class AbstractHuman is interface {
attr head, shoulders, knees, toes;
invar { .head == 1 }
invar { .shoulders == 2 }
invar { .knees == 2 }
invar { .toes == 10 }
method talk ($say,$how_loud);
}
class Human isa AbstractHuman {
method talk ($say,$how_loud) {
$say.uc if $how_loud = 10:
print $say\n;
}
}
The above would result in the same thing. The latter explicitly seperates
the interface from the implementation, as some like, while the former does
them all in one class, as others like.
If you want to have a public and private inheritable interfaces that's
fine. But what's the point of a non-inheritable interface? Myself, I call
non-inheritable methods functions.
Interface is not quite simply the union of method signature,
conditions and invariants. Interfaces are a combination of the three,
true, but it's only a subset of their use. They're all useful beyond simply
enforcing how subclasses are designed and implemented.
Method signatures are obviously used to define how methods are to be called
by outside users of the object, as well as change the contexts in which the
arguments are parsed.
Pre/post conditions and invariants, when private (ie. not inherited) can be
used like assertions, guaranteeing that internal state and implementation
details are kept sane. My ATV example may not have been clear enough in
that I considered the tilt check to be an internal state check and not a
documented feature of the object. A clearer example might be something like
checking that an internal data structure used by the object is not circular.
A class invariant, yet not something I want to enforce on my children.
They're tools that when combined form an interface but are still useful
seperately.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
The key, my friend, is hash browns.
http://www.goats.com/archive/980402.html
Re: Private contracts?
On Thu, Oct 03, 2002 at 06:46:14PM -0400, Michael G Schwern wrote:
I see us already smashing too many things into the method signature as it
is. It will rapidly get messy if you have a method with a complex signature
and a handful of attributes and preconditions.
I think I have my own counter example.
Consider defining an abstract class with an interface and I want to put some
conditions onto an abstract method.
class Abstract::Human is interface {
attr head, shoulders, knees, toes;
invar { .head == 1 }
invar { .shoulders == .knees == .toes == 2 }
method eat ($food) is pre { !$food.isa('Poison') }
is post { .return eq 'Burp' }
}
since I have no method body for eat() I have no choice but to hang it off
the signature as an attribute.
So conditions do have to go on the signature, but I still like the option of
their being in the body as well, especially given the problem of wanting to
put post conditions at the end.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Cottleston, Cottleston, Cottleston Pie.
A fly can't bird, but a bird can fly.
Ask me a riddle and I reply:
Cottleston, Cottleston, Cottleston Pie.
Re: Delegation syntax?
On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote:
On Thu, Oct 03, 2002 at 03:54:09PM -0700, Michael Lazzaro wrote:
I have no *good* syntax proposals for this, I don't think I've ever
seen the problem solved with syntax that I really ever liked.
Class::Delegation?
Yeah, it's one of the best I've seen: it makes sense, does everything I
want, and is easy to explain even to newbies. The perl5 hash-based
syntax is still pretty scary, tho.
Dunno, I keep wishing for something that's a one-liner for simple
cases. I guess something like:
# $.data_manager receives all method calls for which
# it has a matching public interface.
class DataSnippet {
attr $data_manager is DataManager receives ( -ALL );
}
# alternative syntax, also useful on a method-by-method basis...
# Note that if steer() has an implementation, it's dispatched there
too.
class Car is interface {
attr $left_front_wheel;
attr $right_front_wheel;
...
method steer ( ... ) is dispatched( $left_front_wheel,
$right_front_wheel ) { ... };
}
Incidentally, I think the Car above is an example of why it might be ok
to allow attributes in interfaces. (I would definitely argue it's ok
to give default method implementations in interfaces. You don't have
to if you don't believe in it, but hey, some people prefer it.) You're
basically saying that the interface attaches these named attribs to
anything that use it. It usually isn't considered proper, but I don't
know if it's evil enough to explicitly disallow.
The biggest problem I see with interface attribs myself is
implementational, not philosophical; if you've got attribs being
assembled from multiple interfaces, it makes implementation of
subclasses even more difficult to optimize. (Of course, we already
have multiple inheritance, so that ship's probably long sailed already.)
MikeL
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, 3 Oct 2002, Michael Lazzaro wrote:
1) Delegation through inheritance:
(a.k.a. mixin classes, hard delegation, concrete interfaces,
etc., etc.)
Example: I want to say that a class DataManager has the capabilities
of the interfaces DataStrategy and CacheStrategy, but is not strictly a
subclass of either. In other languages, this might appear like:
class DataManager implements DataStrategy, CacheStrategy { ... }
- or -
class DataManager mixin DataStrategy, CacheStrategy { ... }
Aside from runtime mixin', in what way does inheritance _not_ do what you
want?
2) Delegation through attribute:
(a.k.a soft delegation, instance-based delegation, etc., etc.)
The ability to specify that, if an instance of an object DataSnippet
is affiliated with a specific, runtime instance of a DataManager, e.g.
class DataSnippet {
attr $data_manager is DataManager;
}
... then [some, all] public methods of $self.data_manager can
automatically be delegated by the DataSnippet to that specific
instance, eliminating the need for code that makes you want
to kill yourself:
method foo (...) { $self.data_manager.foo( ... ) }
method bar (...) { $self.data_manager.bar( ... ) }
# ... repeat until carpel tunnel syndrome sets in ...
Reaction #1: Only on a perl list would it occur to people to complain
about that. :)
Reaction #2: Inheritance would automatically delegate all those
methods, so again, in what way does inheritance _not_ solve the problem?
Finally, a question about interfaces:
In what way is an interface different from a pure abstract class (i.e.
containing only method declarations, but no code)?
~ John Williams
DISCLAIMER: This post assumes perl6 will have multiple inheritance.
Re: Private contracts?
On Thu, 3 Oct 2002, Trey Harris wrote: Incidentally, has there been any headway made on how you DO access multiple classes with the same name, since Larry has (indirectly) promised us that? I.e., I import two classes LinkedList and BTree, both of which define a Node class? Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines a BTree::Node class. Either by explicitly naming them that or by virtue of being defined as an inner class (which might also make it private). ~ John Williams
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, John Williams writes: On Thu, 3 Oct 2002, Trey Harris wrote: Incidentally, has there been any headway made on how you DO access multiple classes with the same name, since Larry has (indirectly) promised us that? I.e., I import two classes LinkedList and BTree, both of which define a Node class? Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines a BTree::Node class. Either by explicitly naming them that or by virtue of being defined as an inner class (which might also make it private). Ah, but that's the way you do it now--name the classes differently. (Easy--assuming you control the source code!) In Perl 6, we're supposed to be able to use multiple versions of the same class concurrently, which I think would imply also being able to use multiple classes that happened to be named the same thing. Trey
Re: Delegation syntax?
In a message dated Thu, 3 Oct 2002, Michael Lazzaro writes:
On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote:
Class::Delegation?
Yeah, it's one of the best I've seen: it makes sense, does everything I
want, and is easy to explain even to newbies. The perl5 hash-based
syntax is still pretty scary, tho.
Dunno, I keep wishing for something that's a one-liner for simple
cases. I guess something like:
# $.data_manager receives all method calls for which
# it has a matching public interface.
class DataSnippet {
attr $data_manager is DataManager receives ( -ALL );
}
Looks like a simple Perl 6 grammar munge to me--it's a simple postfix
conditional which takes the declaration before it, gets its type (or looks
at the code, TMTOWTDI) and creates accessors in the namspace of the
caller. Doesn't appear particularly magical to me. In fact, if you
didn't mind writing it
attr data_manager = DataManager, receives = -ALL;
you could easily write it in Perl 5 today.
# alternative syntax, also useful on a method-by-method basis...
# Note that if steer() has an implementation, it's dispatched there
too.
class Car is interface {
attr $left_front_wheel;
attr $right_front_wheel;
...
method steer ( ... ) is dispatched( $left_front_wheel,
$right_front_wheel ) { ... };
}
This is doable now too:
dispatch steer = $left_front_wheel, $right_front_wheel;
Could be written in Perl 5, simply enough, as
sub dispatch {
no strict 'refs';
my ($method, dispatchees) = _;
*{caller().::$_[0]} =
sub {
$_-$method(_) foreach dispatchees;
};
}
I think my point here is that there are clearly places where we need
stronger built-in support in Perl of some OO concepts. Delegation may not
be one of them--it's easy enough to graft on, and TMTOWTDI may be good
here.
Incidentally, I think the Car above is an example of why it might be ok
to allow attributes in interfaces. (I would definitely argue it's ok
to give default method implementations in interfaces. You don't have
to if you don't believe in it, but hey, some people prefer it.) You're
basically saying that the interface attaches these named attribs to
anything that use it. It usually isn't considered proper, but I don't
know if it's evil enough to explicitly disallow.
The biggest problem I see with interface attribs myself is
implementational, not philosophical; if you've got attribs being
assembled from multiple interfaces, it makes implementation of
subclasses even more difficult to optimize. (Of course, we already
have multiple inheritance, so that ship's probably long sailed already.)
I don't understand. A public attribute will have an autocreated accessor.
So put the accessor in the interface, not the attribute. If you put the
attribute in the interface, you've committed to having it as an attribute.
If you decide to turn it into a computed method, you're out of
luck--unless you make the attribute a tied variable itself (gak!).
Trey
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, Oct 03, 2002 at 07:59:33PM -0600, John Williams wrote: Reaction #2: Inheritance would automatically delegate all those methods, so again, in what way does inheritance _not_ solve the problem? I don't think p6l is the right place to discuss the merits of delegation, let's just say it's a Good Thing to have in your OO toolbelt. Solves a lot of problems which would otherwise require hairy, ambiguous multiple inheritance situations. If you're curious I can explain more off-list. Finally, a question about interfaces: In what way is an interface different from a pure abstract class (i.e. containing only method declarations, but no code)? An interface requires subclassers to implement all abstract methods and they must match the method signatures, conditions and invariants of the interface. A pure abstract class doesn't necessarily require subclasses to do anything, at least not in Perl. So an interface is simply a class, maybe abstract, which requires its subclasses to conform to its signature. At least that's how I see it. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One It's Airplane Glue sniffing time!
Re: Delegation syntax?
On Fri, Oct 04, 2002 at 12:28:29AM -0400, Trey Harris wrote: I think my point here is that there are clearly places where we need stronger built-in support in Perl of some OO concepts. Delegation may not be one of them--it's easy enough to graft on, and TMTOWTDI may be good here. Delegation is a basic OO technique. We definately should have fast, well-designed core support for it. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Is there an airport nearby or is that just my tae-kwon-do taking off?
Re: Private contracts?
Michael G Schwern wrote: How exactly does one weaken a precondition? Say I define a mathematical mod() function in my parent number class. precondition: $a 0, $b 0, $b is int mod( $a, $b ) Then in my subclass, I want to make it work in a wider variety of contexts. I change the definition to: precondition: $b is int, $b != 0 mod( $a, $b ) It now properly supports modulo arithmetic for negative numbers, because the requirements for running the function have been weakened. It is still completely substitutable anywhere that the parent implementation would work, but if code is dealing with my subclass it is allowed to work with the weakened precondition. Since your proposal was based upon the idea of having every parent condition apply to child implementations, the possibility for strengthened postconditions falls out of the proposal nicely. But since preconditions work in the opposite direction, they don't quite gel with that particular proposal. Mike Lambert
RE: Private contracts?
In a message dated Thu, 3 Oct 2002, Garrett Goebel writes: Michael G Schwern: On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote: In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. How exactly does one weaken a precondition? You weaken a precondition by adding ORs; you strengthen a postcondition by adding ANDs. As expressions in Perl run a tad beyond simple boolean logic, could you give a concrete example? I don't know what you mean. How can a precondition be anything but boolean? all inherited pre-conditions pass or class' own pre-conditions pass I'm afraid I'm a bit lost here. What does pass mean besides evaluates to true in a boolean context? And if that's what pass means, then can't you just OR the preconditions together, in subclass-to-superclass order? Trey
