On Fri, 11 Oct 2002, Trey Harris wrote:
: When you say subclass, do you mean below the current class in the
: naming heirarchy, i.e.
:
: class BTree;
: our class Node {...}
:
: would create BTree::Node? Or do you really mean *subclass*, i.e., our
: class causes Node to inherit from BTree?
Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
From: Larry Wall [EMAIL PROTECTED]
If we use | and as sugar for any() and all(), then their precedence
should probably be the same as || and .
Should they? I had in mind something just above comparisons. That
way:
if $x == 3 || $y ==
On Sat, 12 Oct 2002, Larry Wall wrote:
: The precedence is screwed up though. It'd have to be
:
: use Acme[ (1;17..) | (2;0..) ];
Or maybe this:
use Acme[1;17..] |
Acme[2;0..];
That doesn't, of course, express any preference for one version over another,
since | logically
On Sat, 12 Oct 2002, Luke Palmer wrote:
: Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
: From: Larry Wall [EMAIL PROTECTED]
:
: If we use | and as sugar for any() and all(), then their precedence
: should probably be the same as || and .
:
: Should they? I had in mind something just above
On Sat, 12 Oct 2002 08:43:46 -0700, Larry Wall wrote:
On Sat, 12 Oct 2002, Graham Barr wrote:
: Or even something like
:
: use Acme[1.0];
Hmm. Looks kinda like a subscript, which could be sliced to give an
acceptable version range:
use Acme[1;0..];
Might it be possible to say
On Sat, 12 Oct 2002, Chris Dutton wrote:
: On Saturday, October 12, 2002, at 01:10 PM, Luke Palmer wrote:
:
: Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
: From: Larry Wall [EMAIL PROTECTED]
:
: If we use | and as sugar for any() and all(), then their precedence
: should probably be the
On Sat, 12 Oct 2002, Graham Barr wrote:
: Or even something like
:
: use Acme[1.0];
Hmm. Looks kinda like a subscript, which could be sliced to give an
acceptable version range:
use Acme[1;0..];
Except slices aren't powerful enough to say what you really want to say:
use
On Saturday, October 12, 2002, at 01:10 PM, Luke Palmer wrote:
Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
From: Larry Wall [EMAIL PROTECTED]
If we use | and as sugar for any() and all(), then their precedence
should probably be the same as || and .
Should they? I had in mind something
On Thu, 3 Oct 2002, Trey Harris wrote:
: 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
On Fri, Oct 11, 2002 at 05:50:55PM -0700, Larry Wall wrote:
On Sat, 5 Oct 2002, Allison Randal wrote:
: use Acme::N-1_0; # or whatever the format of the name is
I don't see why it couldn't just be:
use Acme::1.0;
I agree thats better. But why not separate the version more by
* Larry Wall ([EMAIL PROTECTED]) [12 Oct 2002 10:51]:
[...]
use Acme::1.0;
After all, we don't have package names starting with numbers right now...
Well, there's than Pod::Simple::31337, which confused search.cpan.org for a
bit. But none which _start_ with a number, no.
cheers,
--
On Sat, 5 Oct 2002, Allison Randal wrote:
: use Acme::N-1_0; # or whatever the format of the name is
I don't see why it couldn't just be:
use Acme::1.0;
After all, we don't have package names starting with numbers right now...
Larry
On Fri, 4 Oct 2002, Garrett Goebel wrote:
: That wasn't the way I remembered it from Apoc 4... The following example is
: not in A4, but its what I inferred from it...
:
: Class Foo {
: method eat($food) is abstract {
: PRE { ... }
: POST { ... }
: }
: }
A4 was proposing those for a
On Fri, 4 Oct 2002, Peter Haworth wrote:
: This is the one nice thing about the Pascal-like syntax of Eiffel. It allows
: this situation to be unambiguous and sensibly ordered (as well as giving each
: condition labels, so that violations can be better reported):
:
: foo(this: ThisType, that:
On Thu, 3 Oct 2002, John Williams wrote:
: 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,
On Thu, 3 Oct 2002, Michael G Schwern wrote:
: 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 } {
: ...
: }
:
: #
On 4 Oct 2002, Aaron Sherman wrote:
: There are a very large number of good things that I think we should put
: into properties for meta-programming purposes (e.g. constraints,
: assertions, optimization hints, documentation, etc).
:
: For example:
:
: sub f(int $a is
sub f(int $a is constrained($a=1,must be positive),
documented(an integer)) {
...
}
I now realize I'm a little fuzzy on the yada-yada-yada operator. What
exactly is it... or what does it do? Is it a statement, an
expression? Could you say
In a message dated Fri, 11 Oct 2002, Larry Wall writes:
A public inner class:
our class Node {...}
That last one actually declares a subclass of the current class, just as
our $foo;
puts $foo into the current package.
When you say subclass, do you mean below the current class in
On Friday, October 4, 2002, at 06:23 PM, [EMAIL PROTECTED] wrote:
On Fri, Oct 04, 2002 at 09:13:45AM -0400, Chris Dutton wrote:
How exactly does one weaken a precondition?
At least in Eiffel, if you redefine a method, you may not give it
stringer preconditions than the original method,
On Fri, Oct 04, 2002 at 12:03:44AM -0400, Trey Harris wrote:
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
In a message dated Sat, 5 Oct 2002, Allison Randal writes:
More useful: keep a site-wide or company-wide file of version aliases to
make sure everyone uses the same version, and to make upgrades to the
next version as simple as editing a single file.
Ah, but the usual case is this:
You
On Thursday, October 3, 2002, at 05:19 PM, Michael G Schwern wrote:
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?
At
There are a very large number of good things that I think we should put
into properties for meta-programming purposes (e.g. constraints,
assertions, optimization hints, documentation, etc).
For example:
sub f(int $a is constrained($a=1,must be positive),
On Thu, 3 Oct 2002 18:46:14 -0400, Michael G Schwern wrote:
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
On Thu, 3 Oct 2002 19:16:09 -0400, Michael G Schwern wrote:
On Thu, Oct 03, 2002 at 04:47:26PM -0500, Garrett Goebel wrote:
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,
Michael G Schwern:
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.
--
On Thu, 3 Oct 2002 18:46:14
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.
This is the sort of creeping
Peter Haworth wrote:
That *is* a logical weakening. Just because the inherited precondition is
C x 10 , doesn't mean that the weakened condition has to be of the form
C x 9 or any other value lower than 10. C a || b is weaker than
C a
So what we are looking at is something like
Michael G Schwern:
Garrett Goebel wrote:
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
John Williams:
Reaction #2: Inheritance would automatically delegate all those
methods, so again, in what way does inheritance _not_ solve
the problem?
What about when you want to be able to dynamically swap the objects to which
you're delegating?
--
Garrett Goebel
IS Development
Michael G Schwern:
Garrett Goebel wrote:
Michael G Schwern:
shouldn't we have private invariants and conditions?
no.
Ummm, why?
Maybe I'm just grinding an ax...
If you allow an interface's post conditions and invariants to be overlooked,
then you've got a broken interface.
On Fri, Oct 04, 2002 at 09:13:45AM -0400, Chris Dutton wrote:
How exactly does one weaken a precondition?
At least in Eiffel, if you redefine a method, you may not give it
stringer preconditions than the original method, but you may have
stronger postconditions. In essence, you're not
In a message dated Fri, 4 Oct 2002, [EMAIL PROTECTED] writes:
On Fri, Oct 04, 2002 at 09:13:45AM -0400, Chris Dutton wrote:
How exactly does one weaken a precondition?
At least in Eiffel, if you redefine a method, you may not give it
stringer preconditions than the original method, but
On Fri, Oct 04, 2002 at 02:44:24PM -0500, Garrett Goebel wrote:
shouldn't we have private invariants and conditions?
no.
Ummm, why?
Maybe I'm just grinding an ax...
If you allow an interface's post conditions and invariants to be overlooked,
then you've got a broken
On Fri, Oct 04, 2002 at 06:26:31PM -0400, Trey Harris wrote:
But what does it mean to be stronger? How does Eiffel figure out if
a given precondition is stronger or weaker than another?
Like I said before, boolean logic. Preconditions are OR'd together
(starting with the deepest
Michael G Schwern [EMAIL PROTECTED] wrote:
I can see too many problems with that technique, I think one was
already mentioned where subclasses can unintentionally weaken
preconditions to the point of eliminating them.
Which is, of course, why we OR them, yet AND the postconditions
It is
In a message dated Fri, 4 Oct 2002, [EMAIL PROTECTED] writes:
On Fri, Oct 04, 2002 at 06:26:31PM -0400, Trey Harris wrote:
But what does it mean to be stronger? How does Eiffel figure out if
a given precondition is stronger or weaker than another?
Like I said before, boolean logic.
On Fri, Oct 04, 2002 at 08:21:55PM -0400, Trey Harris wrote:
I can see too many problems with that technique, I think one was
already mentioned where subclasses can unintentionally weaken
preconditions to the point of eliminating them. I'm sort of casting
about looking for another way.
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
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
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
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 {
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
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]
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
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
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,
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
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,
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
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]
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...
}
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
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
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
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
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,
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
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
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
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,
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,
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
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
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
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
67 matches
Mail list logo
