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
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
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
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
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
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
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
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
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
>
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: [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
> "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
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
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
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 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
>
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
> 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
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
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
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:
>
> >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
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'
>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
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
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
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
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
> 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
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
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
>
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
: |
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
| }
|
|means something vaguely like:
33 matches
Mail list logo
