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
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 abou
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
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,
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 (
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
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
(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
(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 Classwi
(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: "publ
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 dee
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
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
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'r
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, 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 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
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 c
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 i
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 preliminary document, written as a tutorial for newbies
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 Special
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 det
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 s
--
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 el
--- 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
>
--- 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
>
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 exa
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
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
>
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
--
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),
docume
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
John Williams wrote:
> Reaction #2: Inheritance would automatically delegate all those
> methods, so again, in what way does inheritance _not_ solve the problem?
Many real life systems are composed from elements, not inherited from
elements. A car is not a wheel, but is composed from 4 (or more
33 matches
Mail list logo
