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
Peter Haworth writes:
: On Wed, 23 Jan 2002 08:30:41 -0800 (PST), Larry Wall wrote:
: > Andy Wardley writes:
: > : Same with 'last/NEXT' - they're so similar
: > : in concept that the implementation details should not matter.
: >
: > You mean last/LAST and next/NEXT, I suspect. But there's anoth
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
=?iso-8859-1?q?Jonathan=20E.=20Paton?= writes:
: >
: > >Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
: > >
: > >You *could* instead consider reversing the arguments to
: > all the list
: > >manipulation operators:
: > >
: > > @result = map @data { mapping() }
: > > @result = grep @data { s
On Wed, 23 Jan 2002 08:30:41 -0800 (PST), Larry Wall wrote:
> Andy Wardley writes:
> : Same with 'last/NEXT' - they're so similar
> : in concept that the implementation details should not matter.
>
> You mean last/LAST and next/NEXT, I suspect. But there's another
> argument for case differentia
[Note: I've resent this - since apparently it never made it
to the list. Can someone please complain offlist if they
did get the previous one?]
>
> >Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
> >
> >You *could* instead consider reversing the arguments to
> all the list
> >manipulation ope
>
> >Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
> >
> >You *could* instead consider reversing the arguments to
> all the list
> >manipulation operators:
> >
> > @result = map @data { mapping() }
> > @result = grep @data { selector() };
> > @result = sort @data { comparison() };
>
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 Wed, Jan 23, 2002 at 08:30:41AM -0800, Larry Wall wrote:
> : INIT, DESTROY, AUTOLOAD, etc., all make sense to me. They really are
> : special blocks that normally only occur once in a file. But CATCH and
> : NEXT are part of normal syntax. I don't think they're any more "unusual"
> : in the
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
17 matches
Mail list logo
