At 6:17 PM -0800 3/22/04, chromatic wrote:
On Tue, 2004-03-16 at 11:57, Dan Sugalski wrote:
(I forgot to reply to this last week)
At 11:51 AM -0800 3/16/04, chromatic wrote:
>Just to be sure, if Class Y inherits from Class X, is X on Y's does
>list?
If class X does X, then yes. (I *really* s
On Tue, 2004-03-16 at 11:57, Dan Sugalski wrote:
(I forgot to reply to this last week)
> At 11:51 AM -0800 3/16/04, chromatic wrote:
> >Just to be sure, if Class Y inherits from Class X, is X on Y's does
> >list?
>
> If class X does X, then yes. (I *really* should've picked better
> names) Cla
At 4:12 PM -0800 3/16/04, Larry Wall wrote:
On Tue, Mar 16, 2004 at 02:57:07PM -0500, Dan Sugalski wrote:
: Classes and roles don't automatically share the same namespace.
I think they do. I want to be able to tell the moment I compile it
whether Foo is a class or a role or (a bareword that will n
On Tue, Mar 16, 2004 at 02:57:07PM -0500, Dan Sugalski wrote:
: Classes and roles don't automatically share the same namespace.
I think they do. I want to be able to tell the moment I compile it
whether Foo is a class or a role or (a bareword that will not succeed
in being either). Roles are jus
At 11:51 AM -0800 3/16/04, chromatic wrote:
On Tue, 2004-03-16 at 11:46, Dan Sugalski wrote:
A class >does< X if X is on the does list of the class or any of the
parents of the class. This class then does the role X.
A class >isa< X if X in on the isa list of the class or any of the
parents
On Tue, 2004-03-16 at 11:46, Dan Sugalski wrote:
> A class >does< X if X is on the does list of the class or any of the
> parents of the class. This class then does the role X.
> A class >isa< X if X in on the isa list of the class or any of the
> parents of the class.
> Alternately, your cla
At 11:05 AM -0800 3/16/04, chromatic wrote:
On Tue, 2004-03-16 at 10:25, Dan Sugalski wrote:
Unless I missed something, child classes inherit parent class roles,
so if I have Foo with a role of X, and Bar inherits from Foo, Bar
does the X role. Looks like inheritance to me...
That's normal inhe
On Tue, 2004-03-16 at 10:25, Dan Sugalski wrote:
> Unless I missed something, child classes inherit parent class roles,
> so if I have Foo with a role of X, and Bar inherits from Foo, Bar
> does the X role. Looks like inheritance to me...
That's normal inheritance and that's fine.
Consider ins
At 10:14 AM -0800 3/16/04, chromatic wrote:
On Tue, 2004-03-16 at 06:42, Dan Sugalski wrote:
Roles are going to get implemented as inheritance--so far I've seen
no technical reason not to, and quite a number of reasons to do so.
People can cope, if they're looking this deeply.
Out of curiosity,
On Tue, 2004-03-16 at 06:42, Dan Sugalski wrote:
> Roles are going to get implemented as inheritance--so far I've seen
> no technical reason not to, and quite a number of reasons to do so.
> People can cope, if they're looking this deeply.
Out of curiosity, what are those reasons?
I'm not sure
At 7:53 PM -0800 3/15/04, Larry Wall wrote:
On Sun, Mar 14, 2004 at 02:32:44PM +0100, Leopold Toetsch wrote:
: Why? A ParrotClass is responsible for the method dispatch. The ParrotObject
: inherits that behavior.
In Perl 6 terms we'd prefer to say that ParrotClass "does" the
Dispatch role, and so d
On Sun, Mar 14, 2004 at 02:32:44PM +0100, Leopold Toetsch wrote:
: Why? A ParrotClass is responsible for the method dispatch. The ParrotObject
: inherits that behavior.
In Perl 6 terms we'd prefer to say that ParrotClass "does" the
Dispatch role, and so does ParrotObject, but to call it inheritanc
Malte Ubl wrote:
> Dan Sugalski wrote:
> > So, if I understand this right (and I may well not), when you
> > instantiate a metaclass you get a class, and when you instantiate a
> > class you get an object, and since anything you instantiate is an object
> > anyway that means classes are objects.
Dan Sugalski wrote:
So, if I understand this right (and I may well not), when you
instantiate a metaclass you get a class, and when you instantiate a
class you get an object, and since anything you instantiate is an object
anyway that means classes are objects. I'm not entirely sure if
metaclas
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> Piers Cawley <[EMAIL PROTECTED]> wrote:
>>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>>
The terms are misleading a bit here.
- a ParrotClass isa delegate PMC
- a ParrotObject isa ParrotClass
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>>
The one question I have is whether we need to have a "call class
method" operation that, when you invoke
This will have to be quick, but...
Objects, and Classes, and MetaClasses, oh my!
In the beginning, there is MMD.
Ideally as a lexically and dynamically scoped first-class variable.
Dispatching on argument types, value predicates, call site, current
continuation, and all sorts of other useful thin
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>>> The one question I have is whether we need to have a "call class
>>> method" operation that, when you invoke it, looks up the class of the
>>> object and redispat
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> The one question I have is whether we need to have a "call class
>> method" operation that, when you invoke it, looks up the class of the
>> object and redispatches to it, or whether class methods are just
>
On 03/13/04 Mark Sparshatt wrote:
> One difficulty is when calling class methods some languages require that
> you provide the class object as the receiver (Ruby and c# do this) while
> some languages let you use an instance of the class as the receiver
> (Java does this)
I think you're confusi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The one question I have is whether we need to have a "call class
> method" operation that, when you invoke it, looks up the class of the
> object and redispatches to it, or whether class methods are just
> methods called on class objects.
The terms are mi
Dan Sugalski wrote:
So, if I understand this right (and I may well not), when you
instantiate a metaclass you get a class, and when you instantiate a
class you get an object, and since anything you instantiate is an
object anyway that means classes are objects. I'm not entirely sure if
metacla
22 matches
Mail list logo
