On Tue, Oct 25, 2005 at 05:17:40PM -0400, Stevan Little wrote:
: Larry,
:
: On Oct 25, 2005, at 4:37 PM, Larry Wall wrote:
: >On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote:
: >: # behavior through prototype -- guessing realistic syntax
: >: Base.meta.add_method(
: >: do_it => method ($arg) {
: >: say "doing $arg!";
: >: });
: >:
: >:
: >: # or, just add it to a single instance
: >: $x.meta.add_method(
: >: do_it => method ($arg) {
: >: say "doing $arg!";
: >: });
: >
: >I don't have a comment on your actual question, but I'd like to use
: >this opportunity to point out the symmetry of Base and $x at this
: >point, and the fact that .meta can't simply call .add_method in the
: >metaclass, or it would lose track of the original invocant, which is
: >needed to convey both class and instance information. I'm not sure
: >it's even possible to say
: >
: > $m = $x.meta;
: > $m.addmethod($arg);
: >
: >The only way that can work is if $x.meta returns a shadow class that
: >is prebound only to $x. (Though that might explain how .addmethod
: >knows it's only adding a method to the object.)
:
: This is actually the principe behind the Ruby style singleton methods
: (the shadow class), it basically creates an anon-class which inherits
: from $x's original class, then it rebinds/blesses $x into the anon-
: class. It is very simple really :)
Sure, but such a heavy behavior shouldn't be implied merely by trying
to get at the metaclass.
: As for if this is/should be accessible through .meta, i am not sure
: that is a good idea. The reason being is that .meta brings with it
: the idea of metaclasses, which then relates to classes, and so now
: the user is thinking they are accessing the metaclass of the class of
: which $x is an instance.
:
: I would suggest instead that we have a method, which is found in
: Object which allows instances to add methods to themselves (and only
: themselves). In Ruby this is called 'add_singleton_method' or
: something like that. I use that same name in the metamodel prototype
: too.
That's fine, and fits in with Prototype-Think anyway.
: Here is how it could be done.
:
: class ShadowClass does Class {}
:
: class Object is reopened {
That might change to "is also", the generic trait for appending to things
that may or may not be classes. (And "is instead" is used to replace things.)
: method add_singleton_method (Str $label, Method $method) {
: if ($?SELF.class.class != ShadowClass) {
s/$?SELF/self/
And I think .class should be a coercion to the "class" view of its
invocant, which would make your second .class a no-op. I think what
you're calling .class.class I'm calling .meta.class. I want to
think of the class as an abstraction that is not an object. Everything
you call Class I want to sweep behind .meta, because the metaclass instance
is the real class object.
: my $shadow = ShadowClass.new();
: $shadow.meta.superclasses([ $shadow ]);
: $?SELF.class = $shadow;
I think that should be self.meta = $shadow. .class is not an
lvalue--it's just a restricted view of the current object. (Again,
by my definitions. I realize clashing definitions are at work here.
Maybe I can come up with a different word for what I call "class".
Or maybe I get "class", and you get "Class" :-) * .5
: }
: $?SELF.class.meta.add_method($label, $method);
That's just self.meta.add_method($label, $method) by my lights.
A .meta already implies/ignores the .class coercion. If we are to
support prototype-based programming $x.meta *must not care* whether
it has been given a class or an instance or something in between.
What I am calling a "class" here is basically that portion of the
current instance that is the same for all members of its class.
And that common information presumably includes information on what to
do if a method is called that is not directly recognized by the object.
Class-based and prototype-based systems have different answers to that,
but they have something in common, and I'd like to abstract that out
and call it something. I've been calling it "class", but maybe I
should call it something else to avoid confusion. A "type" maybe.
That would imply that ¢ is really a "type" variable rather than a class
variable. But maybe "type" is too overloaded already. But maybe not.
Anyway, if my "class" turns into "type" or something else, maybe I
can be persuaded to go with ^T instead of ¢T.
Larry
