Tony Olekshy writes:
: In Apocalypse 4, Larry Wall wrote:
: |
: | In fact, a C of the form:
: |
: | CATCH {
: | when xxx { ... } # 1st case
: | when yyy { ... } # 2nd case
: | ... # other cases, maybe a default
: |
On Tue, 22 Jan 2002 10:03:08 -0800 (PST), Larry Wall wrote:
> At the moment, I see this:
>
> -2. PRE in order, inherited, no side effects
> -1. FIRST in order
> 0. inline code normal flow
> 1. CATCH, CONTROLsingular
>
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> This is all very sensible, and I completely agree with it.
> However, don't we
> need some restrictions on what can go in PRE and POST blocks
> to ensure that they are still valid in inherited methods?
There's another issue: sometimes we don't
> The problem I see with inheriting subblocks such as
> FIRST/LAST/etc, is that they are tied in with the logic
> ... of their enclosing block...
Surely this is an argument *for* it being pretty odd
*not* to inherit them.
Let's say you add a LAST block to a method. In the
LAST block you write cl
From: Me [mailto:[EMAIL PROTECTED]]
>
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
>
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
>
> Let's say you add a
From: David Whipp [mailto:[EMAIL PROTECTED]]
> Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> > This is all very sensible, and I completely agree with it.
> > However, don't we
> > need some restrictions on what can go in PRE and POST blocks
> > to ensure that they are still valid in inherite
Me writes:
: > The problem I see with inheriting subblocks such as
: > FIRST/LAST/etc, is that they are tied in with the logic
: > ... of their enclosing block...
:
: Surely this is an argument *for* it being pretty odd
: *not* to inherit them.
:
: Let's say you add a LAST block to a method. In
Me wrote:
>
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
>
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
>
> Let's say you add a LAST block to a method. I
>Methinks (that's me, not you) that if me thinks (that's you, not me)
>that my argument is an argument *for* it being pretty odd *not* to
>inherit them, that there is an assumption by me or me (that's one or the
>other of us) that is clearly wrong about the way inheritance of methods
>(should) wo
David Whipp writes:
: Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
: > This is all very sensible, and I completely agree with it.
: > However, don't we
: > need some restrictions on what can go in PRE and POST blocks
: > to ensure that they are still valid in inherited methods?
:
:
: There'
Melvin Smith wrote:
>
> >Methinks (that's me, not you) that if me thinks (that's you, not me)
> >that my argument is an argument *for* it being pretty odd *not* to
> >inherit them, that there is an assumption by me or me (that's one or the
> >other of us) that is clearly wrong about the way inher
At 02:25 PM 1/23/2002 -0800, Glenn Linderman wrote:
>Melvin Smith wrote:
> > I'm not comfortable with this sort of concept. Typically "inheritance" is
> > going to either take the base implementation or _replace_ the
> implementation.
> > The replacement can decide to {call|ignore} the base metho
Melvin Smith wrote:
>
> > > If you wouldn't want the base implementation to be ignore there is usually
> > > some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
> > > sure.
> >
> >I'm not sure either. In fact, I'm not sure what you mean by this
> >sentence at all. If it matt
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
> I think you just said the same thing I did. To be more explicit, using
> the terminology you seem to want to use, I'll point out that I was only
> talking about the case of an inherited method, not a _replacement_
> method. In ot
> I think our terminology is getting sloppy here.
Ok, I (think I) understand. It's simple:
If you declare a derived method, then preconditions
and postconditions may or may not be inherited, and
independently, the code may or may not be inherited.
By default, the conditions are inherited and th
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
At 02:45 PM 1/23/2002 -0800, Glenn Linderman wrote:
>Melvin Smith wrote:
> > Referring to final, private, etc. modifiers that you can use in C++/Java
> > whenever you don't want someone reimplementing or overriding something.
>
>final and private are completely different concepts as I understand
>
On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote:
> Final seems to be a way of sealing off a class or method from future
> inheritance. Generally, the arguments I've seen on OO lists seem to
> indicate that regardless of how omniscient the original designer is,
> someone will get a
At 05:01 PM 1/23/2002 -0600, Jonathan Scott Duff wrote:
>On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote:
> > Final seems to be a way of sealing off a class or method from future
> > inheritance. Generally, the arguments I've seen on OO lists seem to
> > indicate that regardless o
Graham Barr wrote:
>
> On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
> > I think you just said the same thing I did. To be more explicit, using
> > the terminology you seem to want to use, I'll point out that I was only
> > talking about the case of an inherited method, not a
> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
Larry> I think our terminology is getting sloppy here. What do you mean by
Larry> "inherit from that method"? If the derived method overrides the base
Larry> method, it will manage its own resources, and doesn't need the base
Larry> method
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> > "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> Larry> I think our terminology is getting sloppy here. What
> Larry> do you mean by "inherit from that method"? If the
> Larry> derived method overrides the base method, it will
From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
>
> Graham Barr wrote:
> > But the base class may be just an interface class. And thus
> > by inheriting the pre conditions you are enforcing the API.
> > So I can see a use for it, but I can also see where you
> > don't want it too.
>
> So if th
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
>
> > So maybe your point was that when you replace a method from a
> > base class that you only have 1 subroutine for that method,
> > the replacement one, because there wasn't really one there
>
On Thu, 2002-01-24 at 08:48, Garrett Goebel asked:
> So which Apoc will be the OO one?
Apoc 12, to go by the chapters of the 3rd Camel.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
On Wed, Jan 23, 2002 at 06:00:21PM -0500, Melvin Smith wrote:
> >final and private are completely different concepts as I understand
> >them.
>
> I wouldn't say "completely different". They are both used for "enforcement"
> of similar means, but you are correct, they are different.
I view "final
Garrett Goebel writes:
: And this is just looking at it in the simple case. When multiple-dispatch
: comes into the picture, then we'll have different invokations of the same
: method being dispatched to different implementations depending on the
: parameter list. I wonder how PRE/POST will work o
Damien Neil writes:
: On Wed, Jan 23, 2002 at 06:00:21PM -0500, Melvin Smith wrote:
: > >final and private are completely different concepts as I understand
: > >them.
: >
: > I wouldn't say "completely different". They are both used for "enforcement"
: > of similar means, but you are correct, th
On Thu, Jan 24, 2002 at 10:48:45AM -0600, Garrett Goebel wrote:
> When multiple-dispatch comes into the picture, then we'll have
> different invokations of the same method being dispatched to different
> implementations depending on the parameter list. I wonder how PRE/POST
> will work once that c
From: Larry Wall [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel writes:
> : And this is just looking at it in the simple case. When
> : multiple-dispatch comes into the picture, then we'll
> : have different invokations of the same method being
> : dispatched to different implementations dependin
Garrett Goebel writes:
: --_=_NextPart_001_01C1A506.D9BE78D0
: Content-Type: text/plain;
: charset="iso-8859-1"
:
: From: Larry Wall [mailto:[EMAIL PROTECTED]]
: >
: > Garrett Goebel writes:
: > : And this is just looking at it in the simple case. When
: > : multiple-dispatch comes in
Larry wrote:
> : > I strongly suspect that DbC and multimethods are, at best,.
> : > orthogonal My gut level feeling is that multimethod calls look
> : > like ordinary subroutine calls, and the "method" eventually
> : > selected evaluates only its own PRE/POST conditions, which could
> : > perhaps
32 matches
Mail list logo
