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
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
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 metaclasses are objects, but
23 matches
Mail list logo
