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),
At 12:37 AM -0400 10/4/02, Michael G Schwern wrote:
Delegation is a basic OO technique. We definately should have fast,
well-designed core support for it.
I'm pretty sure we will. I certainly need it internally...
--
Dan
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.
--- David Whipp [EMAIL PROTECTED] wrote:
Kv Org [mailto:[EMAIL PROTECTED]] wrote
I believe Perl6 needs a facility to run
compartmented code (object-oriented and
module-loading) that is tagged as to its
permissions
and owner ID. The goal would be to let such code
use
harmful actions
--- David Whipp [EMAIL PROTECTED] wrote:
Kv Org [mailto:[EMAIL PROTECTED]] wrote
I believe Perl6 needs a facility to run
compartmented code (object-oriented and
module-loading) that is tagged as to its
permissions
and owner ID. The goal would be to let such code
use
harmful actions
--
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.
From: Michael Lazzaro [EMAIL PROTECTED]
Proposed Remedy: We need to better document our
discussions so that we don't keep having them.
That's a groovy idea. It'll help us all by defining terms and providing
examples to wrap our brains around.
An idea to add to the general concept of Perl6
On Friday, October 4, 2002, at 12:52 PM, [EMAIL PROTECTED] wrote:
Perhaps to go with Apocalypses and Exegeses we could have Psalms, a
bunch
of bitsize perls of wisdom. Except, um, psalms are, by definition,
sacred,
so, um, I dunno, just a thought. Larry?
Perhaps Prophecies. Or
On Fri, 4 Oct 2002, [EMAIL PROTECTED] wrote:
Perhaps to go with Apocalypses and Exegeses we could have Psalms, a bunch
of bitsize perls of wisdom. Except, um, psalms are, by definition, sacred,
so, um, I dunno, just a thought. Larry?
Proverbs?
On Fri, 4 Oct 2002, Michael Lazzaro wrote:
Observation: We're doing a *lot* of talking past each other.
Proposed Remedy: We need to better document our discussions so that we
don't keep having them.
---
I volunteer (*shudder*) to be another grunt secretary and start
compiling a
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
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Attributes:
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Declaring
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Symmetry between
On Fri, Oct 04, 2002 at 03:42:49PM -0600, John Williams wrote:
Derived from the RFCs and subsequent discussions, here is a proposed OO
Bill of Rights: fundamental truths that I *think* are already agreed
upon, and from which all other OO laws must be derived:
(OO Article 1) It should be
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
This all looks good to me. I seem to have gone off on a tangent about
slots, so I've mercifally changed the subject.
On Fri, Oct 04, 2002 at 04:39:40PM -0700, Michael Lazzaro wrote:
[CONS]
- Making publicly accessible attributes at all is considered Bad Form
in most OO methodologies
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.
Thanks, if it's looking like lvalues are really out I'll edit that draft
to take out the lvalue stuff and do it the other way. (And if Damian's
happy with slots, that probably means we can get a lot of the other
attribute recipies out of the way pretty quick. Huzzah!)
I had mixed feelings
At 4:39 PM -0700 10/4/02, Michael Lazzaro wrote:
Under the principle of TMTOWTDI, perl allows public attributes
within a class. However, you must explicitly declare an attribute
to be public.
There won't be any direct access to attributes outside class methods
of the class that defines the
31 matches
Mail list logo
