From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Thu, 21 Jun 2007 00:27:07 -0500
On Wed, Jun 20, 2007 at 10:38:08PM -0400, Bob Rogers wrote:
> From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>
> . . . If I want to define a
> new method or or override an existing method on a metaclass instance
> [a class], then how do I do that?
>
> AFAICS, there isn't currently a good way to do that. (Depending, of
> course, on whether you think Jonathan's suggestion qualifies. ;-)
> Nor does PDD15 seem to cover this; it actually says very little about
> metaclasses, beyond just the fact that they exist (and even then only
> mentions class metaclasses).
To somewhat see where I came from in this, pdd15 has a =head3 section
titled "Class Methods", where all of the methods appear to be
operations on classes, as opposed to instances of the class.
IMHO, these are not "Class Methods" in the Ruby sense of being methods
on a particular Class instance, but "Class metaclass methods",
i.e. methods defined for all Class instances.
There's also a line in pdd15 that reads:
=item - Classes are instances of a meta-class and have their
own sets of class methods and class attributes
So, I was wondering how one would create a class method.
Seems like this ought to be two items:
=item - Classes are instances of a meta-class
=item - Classes have their own sets of class methods and class attributes
since they are (arguably) independent. In any case, it seems that the
second part needs more API spec (not to mention an implementation).
> The particular instance I'm looking at is a C<Str> class for
> Perl 6, where I want the get_string vtable function for the
> C<Str> metaclass instance is different from get_string of
> a C<Str> class object.
>
> To me, the phrases "C<Str> metaclass instance" and "C<Str> class object"
> sound like the same thing. Did you mean "C<Str> object" in the second
> case?
I did. Apologies for the ambiguity.
No need to apologize; there may be some who can throw in the right
number of "meta's" all the time, but I'm not one of them. ;-}
. . .
I was wanting to know how to do something similar, except with
get_string instead of typeof. In particular, the example I've
been thinking of is:
$P0 = get_class "Str" # get the Str class
$P1 = new $P0 # create a Str instance
assign $P1, "XYZ" # give it a value
$S0 = $P0 # returns "Str"
$S1 = $P1 # returns "XYZ"
In short, I was wondering how I would get a class to stringify
to its name (or possibly some mocked value), while having
the instances of that class continue to stringify to their values.
Thank you; that's quite clear.
Getting the class instance and the object instance to stringify
differently ought to be straightforward, since they are of different
classes ("Class" and "Str" respectively). The problem is that you want
to affect just the way the Class instance for Str stringifies, without
affecting any other Class instances. (Right?)
If so, and IIUC, Parrot doesn't have direct support for this. Your
best bet for the time being might be to emulate the Ruby subclassing
technique by creating a StrClass (a subclass of Class) whose only
instance is Str. If you generalized this to a Perl6Class (also a
subclass of Class) with a class_name_string slot used by the get_string
method, then you could do the same thing for other Perl 6 classes.
Since get_string is a vtable method, and since I doubt there is any
real call for supporting vtable method dispatch on specfic objects, I
don't think the Lisp technique I mentioned is appropriate.
As I mentioned above, my re-reading of S12 may make this
particular question moot, although it's important to note
that Jonathan apparently encountered something like it as
well. :-) . . .
Regardless, I think you've touched on a general problem that requires a
general solution. Since Ruby is the only language with which I have any
acquaintance that provides both class methods and a metaobject protocol,
and since I have only a superficial understanding of Ruby's MOP, I am
not the one to propose such a solution.
FWIW, I find it interesting that Common Lisp provides a rich MOP that
allows you to make fairly substantial changes to the way objects work,
but doesn't support "class methods" as such -- you can define a method
on a particular class object, but there is no syntactic sugar, for
either definition or invocation, so people just don't do that. This may
be a conscious design decision, or it may be that the basic protocols
evolved before language designers came to believe that class methods
were necessary. Not that it makes any difference to Parrot, but I
wonder if class methods aren't in fact a kludge that a sufficiently
powerful MOP makes unnecessary?
Not sure if this helps, but at least it shouldn't hurt. Much. ;-}
-- Bob
