A12: a doubt about .meta, .dispatcher and final methods
Aldo Calpini
sorry if this has been discussed before, I did a quick search in the
Archive and the summaries but can't find a similar topic.
I've just read A12, and while I really like the inherent orthogonality
of the whole object system as it is (will be) implemented, there is
something that puzzles me. from what I read, it seems that every class
will implicitly call "does Dispatch" (which provides a .dispatcher
method) and "is Object" (which provides a .meta method). (or more
probably, class Object "does Dispatch" itself). so, if this is true, I
guess I could never write a class that does:
class MyClass {
has LethalWeapon $.dispatcher;
method meta { say "$_ is doing meta!" }
}
both of them would make my class pretty useless, I think, since it could
not (correctly, at least) dispatch methods anymore. and I won't be able
to access metadata.
what would Perl6 do in such a case? I think it should complain, and
probably don't let me compile such a class, but what is the underlying
implementation for this? are .dispatcher, .meta (and maybe some others
too) "special" methods that can't be, in any case, overloaded?
and eventually, can I use a similar mechanism in my own classes, that
is, write a "final" method (something like: you can derive from me
however you like, but you can't redefine this method of mine)?
cheers,
Aldo
Aaron Sherman
> class MyClass {
> has LethalWeapon $.dispatcher;
> method meta { say "$_ is doing meta!" }
> }
>
> both of them would make my class pretty useless, I think, since it could
> not (correctly, at least) dispatch methods anymore. and I won't be able
> to access metadata.
It's a fine point... in the past, P5 and P6 have up-cased such
constructs in order to warn of their semi-keywordishness (e.g. DESTROY
or BUILD). I'm wondering why Larry chose to leave dispatcher and meta
lower in this case.
However, in existing CPAN modules that I happen to have in my cache at
the moment:
$ grep -ri 'sub meta' .
./Convert-ASN1-0.18/inc/Module/Install/Metadata.pm:sub Meta { shift }
$ grep -ri 'sub dispa' .
./Module-Build-0.23/lib/Module/Build/Base.pm:sub dispatch {
./Module-Build-0.23/lib/Module/Build/Platform/MacOS.pm:sub dispatch {
./Module-Build-0.23/blib/lib/Module/Build/Platform/MacOS.pm:sub dispatch {
./Module-Build-0.23/blib/lib/Module/Build/Base.pm:sub dispatch {
So it's not THAT bad.
Good catch.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Larry Wall
: It's a fine point... in the past, P5 and P6 have up-cased such
: constructs in order to warn of their semi-keywordishness (e.g. DESTROY
: or BUILD). I'm wondering why Larry chose to leave dispatcher and meta
: lower in this case.
Hmm, yes. Well, I chose those for a very strong reason--I hadn't
thought about the issue yet. :-)
I often throw things into Apocalypses that are "placeholders" when I
know there wants to be something there, but I don't necessarily know
what the right name is yet.
Generally I think of the uppercase names as ones that get called
automatically most of the time. But there's also a history of
uppercasing reserved names in general. (Though most of these are
turning into ordinary variable names like $*OUT and @*ARGS). So we
could uppercase these.
On the other hand, $obj.META.does is ugly. But maybe it should be ugly.
On the third hand, maybe we should go for $obj._meta_ or some such.
On the fourth hand, maybe it's okay to stick with .meta.
On the fifth hand, since it's aiming at a MetaClass, maybe it should
be C<.Meta>.
On the sixth hand, by that argument, since .dispatcher is aiming at
a Class, it should be an uppercase C<>. :-)
: However, in existing CPAN modules that I happen to have in my cache at
: the moment:
:
: $ grep -ri 'sub meta' .
: ./Convert-ASN1-0.18/inc/Module/Install/Metadata.pm:sub Meta { shift }
: $ grep -ri 'sub dispa' .
: ./Module-Build-0.23/lib/Module/Build/Base.pm:sub dispatch {
: ./Module-Build-0.23/lib/Module/Build/Platform/MacOS.pm:sub dispatch {
: ./Module-Build-0.23/blib/lib/Module/Build/Platform/MacOS.pm:sub dispatch {
: ./Module-Build-0.23/blib/lib/Module/Build/Base.pm:sub dispatch {
:
: So it's not THAT bad.
Yeah, well, we do have to worry about future proofing. Whether that's
done culturally or technologically is another matter. I guess another
consideration is whether there's any valid reason for a class to want
to redefine .meta knowing that it's supposed to return the metaclass.
If so, that would tend to argue it should be kept .meta. But that's
a weak argument, as arguments go.
: Good catch.
Yup.
Larry
Dan Sugalski
>On Fri, Apr 23, 2004 at 10:37:00AM -0400, Aaron Sherman wrote:
>: It's a fine point... in the past, P5 and P6 have up-cased such
>: constructs in order to warn of their semi-keywordishness (e.g. DESTROY
>: or BUILD). I'm wondering why Larry chose to leave dispatcher and meta
>: lower in this case.
>
>Hmm, yes. Well, I chose those for a very strong reason--I hadn't
>thought about the issue yet. :-)
>
>I often throw things into Apocalypses that are "placeholders" when I
>know there wants to be something there, but I don't necessarily know
>what the right name is yet.
>
>Generally I think of the uppercase names as ones that get called
>automatically most of the time. But there's also a history of
>uppercasing reserved names in general. (Though most of these are
>turning into ordinary variable names like $*OUT and @*ARGS). So we
>could uppercase these.
>
>On the other hand, $obj.META.does is ugly. But maybe it should be ugly.
>
>On the third hand, maybe we should go for $obj._meta_ or some such.
>
>On the fourth hand, maybe it's okay to stick with .meta.
>
>On the fifth hand, since it's aiming at a MetaClass, maybe it should
>be C<.Meta>.
>
>On the sixth hand, by that argument, since .dispatcher is aiming at
>a Class, it should be an uppercase C<>. :-)
On the seventh hand, why not make it a property that can be put on
any method, which punts the problem out a whole 'nother level? :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Juerd
Larry Wall skribis 2004-04-23 8:24 (-0700):
> On the third hand, maybe we should go for $obj._meta_ or some such.
I don't like _foo_ names. Once you shart having things with underscores,
it's only a matter of time before someone decides that _foo, foo_, _foo,
__foo, ___foo, and __foo__ should all have something specific to say
about what the foo is.
__LINE__, __PACKAGE__, etcetera are fine with me (although I do use
CLASS.pm to be able to type CLASS and get something that often eq
__PACKAGE__), but I wouldn't like other uses of underscores for
important things in the core language.
> On the sixth hand, by that argument, since .dispatcher is aiming at
> a Class, it should be an uppercase C<>. :-)
Doesn't unicode have that, then? :)
Juerd
Aldo Calpini
> However, in existing CPAN modules that I happen to have in my cache at
> the moment:
>
>
> So it's not THAT bad.
hmmm... I think you should probably also grep for modules that do something
like:
my $self = {
meta => 'something',
dispatcher => $something,
# ...
};
return bless $self;
if Perl5 objects are to be implemented somewhat 'transparently' in Perl6,
things like:
$obj->{meta}
will become:
$obj.meta
when used from Perl6. or not?
cheers,
Aldo
Aaron Sherman
> if Perl5 objects are to be implemented somewhat 'transparently' in Perl6,
> things like:
>
> $obj->{meta}
>
> will become:
>
> $obj.meta
>
> when used from Perl6. or not?
True enough, but this was just a quick exploration of the likelihood
that there would be conflict. An exhaustive analysis I leave up to those
who have time to untar all of CPAN :-)
Seriously though, it's also not as much of a concern as the fact that
the free accessors are going to conflict left and right with modules
that implement their own accessors, often with slightly different
semantics than the auto-accessors in Perl 6 will provide. Converting
CPAN over to Perl 6 is going to be a major pain in the butt, so that's
not really what I was solving for (Perl 5 mode will solve for that in
the short term). I just wanted to add some sense of "if I were writing a
module, how likely would it be that I would spontaneously use meta?".
Aldo Calpini
> [...]
>
> On the sixth hand, by that argument, since .dispatcher is aiming at
> a Class, it should be an uppercase C<>. :-)
why not wash all these hands altogether?
IDEA 1
implementing a "final" trait should be trivial enough (it just throws an
exception when, at class construction time, it sees a method that is eq
a base method marked final). so this could be something like (pretending
Object will be written in P6 rather than "gloriously grungy C code" :-):
class Object {
has MetaClass $.meta is final;
}
this would also allow the following code to not compile:
class HumanBeing {
method die is final {
$_.rest_in_peace();
}
}
class Zombie is HumanBeing {
method die {
return undef;
}
}
so long for B-series splatter movies, but hey :-)
IDEA 2
since the .meta method should be the first thing in the inheritance tree
(unless you negate somehow your inheritance from Object, but in this
case you are supposed to know what you're doing), even if you overload
it, the "correct" .meta should always be available as:
($obj.+meta)[-1]
and once we have $obj.+meth, $obj.*meth and $obh.?meth modeled after
regexp modifiers, I see no reason why we shouldn't have:
$obj.^meta
which, calling the most derived method, should always do the Right
Thing.
cheers,
Aldo
Larry Wall
: On Fri, 2004-04-23 at 17:24, Larry Wall wrote:
: > [...]
: >
: > On the sixth hand, by that argument, since .dispatcher is aiming at
: > a Class, it should be an uppercase C<>. :-)
:
: why not wash all these hands altogether?
:
: IDEA 1
:
: implementing a "final" trait should be trivial enough (it just throws an
: exception when, at class construction time, it sees a method that is eq
: a base method marked final). so this could be something like (pretending
: Object will be written in P6 rather than "gloriously grungy C code" :-):
:
: class Object {
: has MetaClass $.meta is final;
: }
:
: this would also allow the following code to not compile:
:
: class HumanBeing {
: method die is final {
: $_.rest_in_peace();
: }
: }
:
: class Zombie is HumanBeing {
: method die {
: return undef;
: }
: }
:
: so long for B-series splatter movies, but hey :-)
But what if someone has a good reason to override .meta? I basically
hate the idea of "final" in any form, I guess.
: IDEA 2
:
: since the .meta method should be the first thing in the inheritance tree
: (unless you negate somehow your inheritance from Object, but in this
: case you are supposed to know what you're doing), even if you overload
: it, the "correct" .meta should always be available as:
:
: ($obj.+meta)[-1]
:
: and once we have $obj.+meth, $obj.*meth and $obh.?meth modeled after
: regexp modifiers, I see no reason why we shouldn't have:
:
: $obj.^meta
:
: which, calling the most derived method, should always do the Right
: Thing.
Except you want the least derived method, which would be $obj.$meta,
which already means something else...
Larry