At 7:56 PM -0500 2/22/03, Benjamin Goldberg wrote:
Dan Sugalski wrote:
Benjamin Goldberg wrote:
Graham Barr wrote:
Dan Sugalski wrote:
If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a
method before we looked to see if B had a concrete instance of that
method.
Right. The best
Dan Sugalski wrote:
> Benjamin Goldberg wrote:
>> Graham Barr wrote:
>>> Dan Sugalski wrote:
If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a
method before we looked to see if B had a concrete instance of that
method.
>>>
>>> Right. The best you could probably do is n
At 11:46 PM -0500 2/21/03, Benjamin Goldberg wrote:
My bit of example code was merely to demonstrate that UNIVERSAL::can()
from perl5 clearly has the problem that Andy Wardley worries about wrt
"freezing" to a particular definition... Thus, it *may* be a good idea
to *not* provide a user-code-leve
At 12:24 PM -0500 2/22/03, Benjamin Goldberg wrote:
Graham Barr wrote:
On Fri, Feb 21, 2003 at 04:34:42PM -0500, Dan Sugalski wrote:
> If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a
> method before we looked to see if B had a concrete instance of that
> method.
Right. The bes
At 9:33 AM + 2/22/03, Graham Barr wrote:
On Fri, Feb 21, 2003 at 04:34:42PM -0500, Dan Sugalski wrote:
If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a
method before we looked to see if B had a concrete instance of that
method.
Right. The best you could probably do is note wh
Graham Barr wrote:
>
> On Fri, Feb 21, 2003 at 04:34:42PM -0500, Dan Sugalski wrote:
> > If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a
> > method before we looked to see if B had a concrete instance of that
> > method.
>
> Right. The best you could probably do is note where you
On Fri, Feb 21, 2003 at 04:34:42PM -0500, Dan Sugalski wrote:
> If A isa B, we certainly wouldn't want to call A's AUTOLOAD on a
> method before we looked to see if B had a concrete instance of that
> method.
Right. The best you could probably do is note where you found the first AUTOLOAD
so tha
Dan Sugalski wrote:
>
> At 12:06 AM -0500 2/21/03, Benjamin Goldberg wrote:
> >Andy Wardley wrote:
> >>
> >> Dan Sugalski wrote much sense, including these gems:
> >[snip]
> >> > Code must be able to fetch a handle on a particular method for
> >> > later calling
> >>
> >> By this I presume you
At 12:06 AM -0500 2/21/03, Benjamin Goldberg wrote:
Andy Wardley wrote:
Dan Sugalski wrote much sense, including these gems:
[snip]
> Code must be able to fetch a handle on a particular method for later
> calling
By this I presume you mean that the handle would be frozen to the
method as it wa
At 6:24 PM -0500 2/20/03, Mark Jason Dominus wrote:
Dan Sugalski <[EMAIL PROTECTED]>:
At 2:06 PM + 2/19/03, Peter Haworth wrote:
>On Fri, 14 Feb 2003 15:56:25 -0500, Dan Sugalski wrote:
>> I got clarification. The sequence is:
>>
>> 1) Search for method of the matching name in inheritanc
Andy Wardley wrote:
>
> Dan Sugalski wrote much sense, including these gems:
[snip]
> > Code must be able to fetch a handle on a particular method for later
> > calling
>
> By this I presume you mean that the handle would be frozen to the
> method as it was when then handle was fetched? If you l
Dan Sugalski wrote:
>
> At 2:06 PM + 2/19/03, Peter Haworth wrote:
> >On Fri, 14 Feb 2003 15:56:25 -0500, Dan Sugalski wrote:
> >> I got clarification. The sequence is:
> >>
> >> 1) Search for method of the matching name in inheritance tree
> >> 2) if #1 fails, search for an AUTOLOAD
> >>
Dan Sugalski <[EMAIL PROTECTED]>:
> At 2:06 PM + 2/19/03, Peter Haworth wrote:
> >On Fri, 14 Feb 2003 15:56:25 -0500, Dan Sugalski wrote:
> >> I got clarification. The sequence is:
> >>
> >> 1) Search for method of the matching name in inheritance tree
> >> 2) if #1 fails, search for an AUTO
At 2:06 PM + 2/19/03, Peter Haworth wrote:
On Fri, 14 Feb 2003 15:56:25 -0500, Dan Sugalski wrote:
I got clarification. The sequence is:
1) Search for method of the matching name in inheritance tree
2) if #1 fails, search for an AUTOLOAD
3) if #2 fails (or all AUTOLOADs give up) then do MM
On Wed, Feb 19, 2003 at 02:06:55PM +, Peter Haworth wrote:
> Shouldn't we be traversing the inheritance tree once, doing these three
> steps at each node until one works, rather doing each step once for the
> whole tree. MM dispatch probably complicates this, though.
>
> If my derived class ha
On Fri, 14 Feb 2003 15:56:25 -0500, Dan Sugalski wrote:
> I got clarification. The sequence is:
>
> 1) Search for method of the matching name in inheritance tree
> 2) if #1 fails, search for an AUTOLOAD
> 3) if #2 fails (or all AUTOLOADs give up) then do MM dispatch
Shouldn't we be traversing the
At 2:46 PM -0500 2/10/03, attriel wrote:
>>Just to confuse things more, there is a question I have reguarding
multi-methods and inheritance.
Consider class A defines foo() as a multi-method with 3 different
signatures
If class B then sub-classes A and defines a method foo() does it
1 overri
>>Just to confuse things more, there is a question I have reguarding
>> multi-methods and inheritance.
>>
>>Consider class A defines foo() as a multi-method with 3 different
>> signatures
>>
>>If class B then sub-classes A and defines a method foo() does it
>>
>>1 override all foo() methods in A
>>
At 6:13 PM + 2/7/03, Graham Barr wrote:
On Fri, Feb 07, 2003 at 09:39:14AM -0800, Dan Sugalski wrote:
It's a little more confusing that that. When I said only one foo
method, it was in contrast to attributes, where an attribute of a
particular name may appear in an object multiple times--s
On Fri, Feb 07, 2003 at 09:39:14AM -0800, Dan Sugalski wrote:
> It's a little more confusing that that. When I said only one foo
> method, it was in contrast to attributes, where an attribute of a
> particular name may appear in an object multiple times--since
> attributes are class-private, eac
At 9:37 PM + 2/3/03, Nicholas Clark wrote:
On Mon, Feb 03, 2003 at 12:15:32PM -0500, Dan Sugalski wrote:
*) Method: Some sort of action that an object can do. Methods are
global and public--only one foo method for an object. Methods may be
inherited from parent classes, or redefined in a
Dan Sugalski wrote:
> At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
> >Dan Sugalski wrote:
> >> *) Property: A named thing attached to an object. Properties are
> >> global to the object and public--i.e. there's no implicit hiding,
> >> namespaces, or whatnot. There can be only one foo property
On Mon, Feb 03, 2003 at 12:15:32PM -0500, Dan Sugalski wrote:
> *) Method: Some sort of action that an object can do. Methods are
> global and public--only one foo method for an object. Methods may be
> inherited from parent classes, or redefined in a particular class.
> Redefined methods hide
At 8:48 PM +0100 2/3/03, Jerome Quelin wrote:
Dan Sugalski wrote:
At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
>Dan Sugalski wrote:
>> *) Property: A named thing attached to an object. Properties are
>> global to the object and public--i.e. there's no implicit hiding,
>> namespaces, or w
At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
Dan Sugalski wrote:
*) Property: A named thing attached to an object. Properties are
global to the object and public--i.e. there's no implicit hiding,
namespaces, or whatnot. There can be only one foo property on an
object, for example
[...]
Th
Dan Sugalski wrote:
> *) Property: A named thing attached to an object. Properties are
> global to the object and public--i.e. there's no implicit hiding,
> namespaces, or whatnot. There can be only one foo property on an
> object, for example
[...]
> The interpreter must handle class hierarchy stu
At 6:25 PM + 2/3/03, Andy Wardley wrote:
Dan Sugalski wrote much sense, including these gems:
*) Method: Some sort of action that an object can do. Methods are
global and public--only one foo method for an object. Methods may be
inherited from parent classes, or redefined in a particular c
> -Original Message-
> From: Andy Wardley [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Wardley
>
> Dan Sugalski wrote much sense, including these gems:
> > *) Method: Some sort of action that an object can do. Methods are
> > global and public--only one foo method for an object. Methods ma
Dan Sugalski wrote much sense, including these gems:
> *) Method: Some sort of action that an object can do. Methods are
> global and public--only one foo method for an object. Methods may be
> inherited from parent classes, or redefined in a particular class.
> Redefined methods hide parent cla
Okay, just to get some stuff defined and the problem space sorted
before I try and work on it:
Definitions:
*) Object: An opaque thingie with properties, attributes, and methods
*) Property: A named thing attached to an object. Properties are
global to the object and public--i.e.
30 matches
Mail list logo
