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
