Hildo Biersma wrote: > > I think such modules are a bad idea, because their functionality is > typically restricted. Oh? Where do you get that idea? > Altering the language to make that easier seems a > bad idea to me. On the contrary: altering *anything* about Perl to make something easier is quite in keeping with Perl's philosophy. > > 1. By default, pass the invocant via a special var or sub, > > either self(), this(), $ME, $THIS, $SELF, or whatever. > > Forcing multiple authors to use the same 'this' or > 'self' name across modules is not the perl way, Well then, forcing multiple authors to use the same C<caller()> is a bad idea too. Look, it's only the difference wbetween sub meth { my $self = shift; and sub meth { my $self = this; No, I think Nathan has nailed it, spot on, with this proposal. -- John Porter We're building the house of the future together.
- RFC 223 (v1) Objects: C<use invocant> pragma Perl6 RFC Librarian
- Re: RFC 223 (v1) Objects: C<use invocant> p... John Porter
- Re: RFC 223 (v1) Objects: C<use invocant> p... Damian Conway
- Re: RFC 223 (v1) Objects: C<use invocant> p... Nathan Wiger
- Re: RFC 223 (v1) Objects: C<use invocant&g... Hildo Biersma
- Re: RFC 223 (v1) Objects: C<use invoca... John Porter
- Re: RFC 223 (v1) Objects: C<use in... Hildo Biersma
- Re: RFC 223 (v1) Objects: C<u... John Porter
- Re: RFC 223 (v1) Objects: C&... Michael G Schwern
- Re: RFC 223 (v1) Objects... Graham Barr
- Backtracing contexts with self($n) (was R... Nathan Wiger
- Re: Backtracing contexts with self($n... Hildo Biersma
- Re: Backtracing contexts with se... John Porter
- Re: RFC 223 (v1) Objects: C<use invocant&g... Philip Newton
- Re: RFC 223 (v1) Objects: C<use invocant> p... Graham Barr
- Re: RFC 223 (v1) Objects: C<use invocant&g... John Porter