From @masak

<masak> rakudo​: sub foo { say "OH HAI" }; class A { method bar {} };
&A​::bar = &foo; A.new.bar
<p6eval> rakudo 0eaf62​: OUTPUT«OH HAI␤»
<jnthn> oh cunning
<moritz_> !
<masak> monkey typing without the monkey.
* Matt-W sees nothing wrong with that
<masak> Matt-W​: are you quite serious?
<jnthn> I'm not sure it's wrong either.
<Matt-W> yes
<Matt-W> very serious
<jnthn> Remember that while ~block is immutable, routine is mutable.
<masak> good. just checking.
<jnthn> I'm not sure if that's "mutable" in a sense that matters here
<Matt-W> would you propose that you'd only be able to do that to
things which explicitly say you could do that to them?
<masak> then I propose we get rid of MONKEY_TYPING altogether.
<masak> it's just a sham.
<Matt-W> I don't see a reason for MONKEY_TYPING either
<jnthn> but it's teh funny ;-)
<moritz_> oh I'm sure it requires MONKEY_TYPING
<masak> moritz_​: apparently not.
<moritz_> masak​: I meant in an ideal Perl 6
* masak submits a rakudobug
<jnthn> moritz_​: I'm not sure how to efficeintly implement that semantic...
<Matt-W> It either needs to be one way or the other
<jnthn> oh, well, we'll think of a way ;-)

From @pmichaud

On Thu, Sep 24, 2009 at 12​:45​:13AM -0700, Carl Mäsak wrote​:

<masak> rakudo​: sub foo { say "OH HAI" }; class A { method bar {} };
&A​::bar = &foo; A.new.bar
<p6eval> rakudo 0eaf62​: OUTPUT«OH HAI␤»
<jnthn> oh cunning
<moritz_> !
<masak> monkey typing without the monkey.
* Matt-W sees nothing wrong with that
<masak> Matt-W​: are you quite serious?
<jnthn> I'm not sure it's wrong either.
[...]

ISTR another conversation on IRC [1] where it was indicated that
one cannot assign to a subroutine as done above; the symbol
can only be rebound. So the "&A​::bar = &foo;" line above
should probably throw a "cannot modify read-only value" exception.

  [1] http://irclog.perlgeek.de/perl6/2009-07-21#i_1331026

(Yes, Routines are considered mutable, but I think that's only
for wrapping purposes. I don't think one is allowed to directly
assign to a Routine object.)

Beyond that, the reason why the above fails is because of the
long-standing Parrot bug that incorrectly puts methods into
the package namespace (TT #​389 I think). In other words, Parrot acts
as if all methods have an "is export" trait on them. So, assigning
to &A​::bar (incorrectly bound to the method) ends up having the side
effect of modifying the method, when the two really should be disconnected.

Note that binding wouldn't be a problem.

Pm

The RT System itself - Status changed from 'new' to 'open'

From @jnthn

On Thu Sep 24 09​:00​:44 2009, pmichaud wrote​:

On Thu, Sep 24, 2009 at 12​:45​:13AM -0700, Carl Mäsak wrote​:

<masak> rakudo​: sub foo { say "OH HAI" }; class A { method bar {} };
&A​::bar = &foo; A.new.bar
<p6eval> rakudo 0eaf62​: OUTPUT«OH HAI␤»
<jnthn> oh cunning
<moritz_> !
<masak> monkey typing without the monkey.
* Matt-W sees nothing wrong with that
<masak> Matt-W​: are you quite serious?
<jnthn> I'm not sure it's wrong either.
[...]

ISTR another conversation on IRC [1] where it was indicated that
one cannot assign to a subroutine as done above; the symbol
can only be rebound. So the "&A​::bar = &foo;" line above
should probably throw a "cannot modify read-only value" exception.

[1] http://irclog.perlgeek.de/perl6/2009-07-21#i_1331026

(Yes, Routines are considered mutable, but I think that's only
for wrapping purposes. I don't think one is allowed to directly
assign to a Routine object.)

You'd need to add "our" these days. And yeah, it does what you're
expecting now.

sub foo { say "OH HAI" }; class A { our method bar {} }; &A​::bar =
&foo; A.new.bar
Cannot assign to a non-container

Beyond that, the reason why the above fails is because of the
long-standing Parrot bug that incorrectly puts methods into
the package namespace (TT #​389 I think). In other words, Parrot acts
as if all methods have an "is export" trait on them. So, assigning
to &A​::bar (incorrectly bound to the method) ends up having the side
effect of modifying the method, when the two really should be
disconnected.

They are; in fact, you can do​:

sub foo { say "OH HAI" }; class A { method bar {} }; &A​::bar = &foo;
A.new.bar
Nil

It didn't touch the original method since it's not looked up via the
package, or ever installed there. And you are allowed to assign symbols
into a package slot.

So, just wants tests.

/jnthn

From @moritz

Now tested in t/spec/S12-methods/syntax.t

@moritz - Status changed from 'open' to 'resolved'