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 them
we've got,
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?
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:
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 following
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
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
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 better than fine
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 them.
So, with this bit
.
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 point me to a
good explanation
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...
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 needed, but I don't, as yet, understand them.
At 12:09
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*
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) Classes
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
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
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 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
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
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
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 class can
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 of
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
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
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 of that class.
bye
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. A natural meta class is the word noun. It
describes a class of words
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 inheritance
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 confusing
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
methods
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 redispatches to it, or
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 it, looks up the class 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 objects
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 base behaviour
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
33 matches
Mail list logo
