Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>>> subclass - To create a subclass of a class object
>>
>>Is existing and used.
>
> Right. I was listing the things we need in the protocol. Some of the
At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
subclass - To create a subclass of a class object
Is existing and used.
Right. I was listing the things we need in the protocol. Some of them
we've got, some we don't, and some of the stuff we have we
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> subclass - To create a subclass of a class object
Is existing and used.
> add_parent - To add a parent to the class this is invoked on
> become_parent - Called on the class passed as a parameter to add_parent
What is the latter used for?
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Now, there is one big gotcha here -- multimethod dispatch. I'm not
> entirely sure that we can do this properly and still give classes
> full control over how methods are looked for and where they go.
Thinking about MMD a bit more, I can imagine the follo
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Anyway, so much for the 'outside world' view of objects as black box
things that have properties and methods.
[ ... ]
Almost everything we do here is going to be with method calls.
There's very little that I can see that requires any f
Right, so with at least a basic rework of the string stuff in, it's
time to turn our attention to objects and all the stuff that goes
with them.
I'd originally thought that the bits we'd put in place would be
sufficient to do everyone's object system (well, all the languages
that we explicitly
On Mon, 4 Oct 2004 13:24:58 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >On Mon, 4 Oct 2004 11:45:50 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> Okay, color me officially confused. I'm working on the assumption
> >> that metaclasses are nee
Dan Sugalski wrote:
At 12:09 PM -0400 10/4/04, Michael Walter wrote:
http://members.rogers.com/mcfletch/programming/metaclasses.pdf
I do have that one. Unfortunately it's the PDF of slides and, while it
looks like if I was at the talk it'd all make sense, without the talk
that goes with 'em... no
t so much sense.
On Mon, 4 Oct 2004 11:45:50 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, color me officially confused. I'm working on the assumption
that metaclasses are needed, but I don't, as yet, understand them.
So, with this bit of ignorance exposed, could someone poi
http://members.rogers.com/mcfletch/programming/metaclasses.pdf
On Mon, 4 Oct 2004 11:45:50 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, color me officially confused. I'm working on the assumption
> that metaclasses are needed, but I don't, as yet, understand the
Okay, color me officially confused. I'm working on the assumption
that metaclasses are needed, but I don't, as yet, understand them.
So, with this bit of ignorance exposed, could someone point me to a
good explanation of what they are and how they work? Theory's fine
(possibly b
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
t means classes are objects. I'm not entirely sure if
> > metaclasses are objects, but it seems to lack a certain amount of
> > egregious symmetry if it doesn't.
> Meta classes break the "every class has a super class"-chain by
> inheriting from themselves.
re if
metaclasses are objects, but it seems to lack a certain amount of
egregious symmetry if it doesn't.
Meta classes break the "every class has a super class"-chain by
inheriting from themselves. A natural meta class is the word noun. It
describes a class of words and it is an instance
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
re if
metaclasses are objects, but it seems to lack a certain amount of
egregious symmetry if it doesn't.
metaclasses are objects as well.
That means, I think, that you ought to be able to call methods on
classes, which since you can I think we're mostly OK, though I expect
some reworking of
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 ob
34 matches
Mail list logo
