Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Another quick one: .as<ancestor>

3 views
Skip to first unread message

Aaron Sherman

unread,
Jul 12, 2006, 12:51:57 PM7/12/06
to Perl6 Language List
I would assume that all classes automatically define:

multi submethod *infix:<as> ($self: $?CLASS) { $self }

so that derived classes can automatically:

$obj.as<ancestor>

Without actually changing their implementation details (only the type
that Perl currently thinks it's dealing with polymorphically).

In fact, I would expect that this bit of behind-the-curtain magic is how
the MCP arranges for polymorphism when you:

sub foo(Object $x) {...}
my A $y;
foo($y);

Is all of that fair?

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback


Larry Wall

unread,
Jul 12, 2006, 8:52:57 PM7/12/06
to Perl6 Language List
On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
: I would assume that all classes automatically define:

:
: multi submethod *infix:<as> ($self: $?CLASS) { $self }

Hmm, "as" is really only intended for explicit type mutation (which
can work either by role mixin or by new object construction). It's
not intended to give Perl a different "view" of an unmutated object.

: so that derived classes can automatically:
:
: $obj.as<ancestor>

Nit: that's illegal syntax. Or rather, it's legal, but you're saying

$obj.as.{'ancestor'}

which is an attempt to do a hash subscript on whatever .as returns.
Only () and : cause arguments to be passed to .as. So you have to
write one of

$obj.as(Foo) # or .(Foo), \.(Foo), etc.
$obj.as: Foo

(Note that those work because Foo is predeclared, presumably.)

: Without actually changing their implementation details (only the type


: that Perl currently thinks it's dealing with polymorphically).

Perl doesn't keep track of that in general except by marking a container
at compile time with the expected type. But an object is always just
itself, unless you go through some kind of proxy or container.

: In fact, I would expect that this bit of behind-the-curtain magic is how


: the MCP arranges for polymorphism when you:
:
: sub foo(Object $x) {...}
: my A $y;
: foo($y);

If you ask for the type of $x within foo(), it will tell you A, not Object.
(The type of variable($x) is Object, however.)

The behind-the-curtain polymorphic magic you're thinking of is really
handled within the various dispatchers, which call various methods
as if they were subroutines rather than methods. That's how the
"lying" happens, generally.

Larry

Aaron Sherman

unread,
Jul 13, 2006, 10:25:09 AM7/13/06
to Larry Wall, Perl6 Language List
On Wed, 2006-07-12 at 17:52 -0700, Larry Wall wrote:
> On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
> : I would assume that all classes automatically define:
> :
> : multi submethod *infix:<as> ($self: $?CLASS) { $self }
>
> Hmm, "as" is really only intended for explicit type mutation (which
> can work either by role mixin or by new object construction). It's
> not intended to give Perl a different "view" of an unmutated object.

Thanks. I think I got compile-time polymorphism confused with run-time
mutation. These are moose of vastly different colors.

0 new messages