HaloO,
Stevan Little wrote:
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 :)
Yes, it's the typical case were an implementation is way easier than
the (type) theoretical modelling of such a simple "pointer" reassignment.
Assignment in general is very difficult to model, actually.
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.
Indeed, we should drop the association of meta with class. There should
be just meta *information* (MI) which is sort of opaque to the general
public. The .meta method should return a MIO (Meta Info Object, My Internal
Object, or what ever) from the MIR (Meta Info Repository). Note that mio in
italian means 'my' or 'mine' depending on the grammatical slot.
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.
In the absence of that, what's going on seems more like
$x.META::addmethod($arg);
where META:: is smart enough to dispatch to the proper metaclass without
throwing away the invocant, and then the metaclass decides what to do
based on the instancehood of $x.
Since we have imperative runtime forms of 'does' for role composition
why not the equivalent on the 'has' installer. But I know it reads bad.
$x has &action;
$x has &.action = &action; # code slot form
$x does &action; # &action wrapping role created on the fly?
$x gets &action; # new keyword?
But IIRC, re-opening of classes is now done with 'is also' and 'does also'
for extending and 'is instead' and 'does instead' for replacing
functionality. This reads better imperatively on the instance level:
$x has also &action;
In the prototype style the my form could use a class style declarator
block:
my $point
{
has Num $.x = 0;
has Num $.y = 0;
method magnitude { sqrt( $.x**2 + $.y**2 ) }
}
$a = $point; # kind is implicitly copied, that is $a.kind == $b.kind
$b = $point; # which could also be tested with ^$a == ^$b or $a =^= $b
$a.x = 3; # easy with COW and a pseudo-hash implementation of $point kind
$a.y = 4;
say $a.magnitude; # prints 5
I am not sure I like this for 2 reasons.
1) META:: smells like ::SUPER, and that feels like re-dispatching to
me, which is not really what we need to be doing.
I agree. Adding to an object incrementally slides it out of it's class's
kind to ultimately become its own singleton kind. Hmm, this gives us a
beautifully ugly cast operator syntax
$foo.kind = Bar; # re-bless
$foo.kind(Bar); # same?
Bar.bless($foo); # same?
$foo ^= Bar; # kind assignment available?
if Bar{$foo} # theorytic query
{
$foo.kind = Bar; # success guaranteed, I almost wrote: guaran-tied :)
}
$foo.kind = Bar if Bar{$foo}; # as statement modifier
to make such a transition in a single jump. The ^Bar kinding/blessing
of $foo might not succeed unless ^Bar is prepared to accept ^$foo kinds,
though.
And, I think perlkind is expecting persistence of referential identity of
$foo independent of the success or failure of the re-blessing. I guess there
should be a dedicated exception kind to handle that. So you can sport a very
experimental, explorative programming style.
--
