Front page | perl.perl5.porters |
Postings from December 2010
On 13 December 2010 10:42, Abigail <abigail@abigail.be> wrote:
> On Mon, Dec 13, 2010 at 09:07:00AM +0100, Johan Vromans wrote:
>> [Quoting Eric Brine, on December 13 2010, 02:51, in "Re: [perl #80628] [P"]
>> > On Mon, Dec 13, 2010 at 2:09 AM, Johan Vromans <jvromans@squirrel.nl> wrote:
>> >
>> > > More important is whether it is a keyword, or a compile time constant
>> > > like __FILE__ and __LINE__.
>> > >
>> > > -- Johan
>> > >
>> >
>> > As proposed, it's not constant.
>>
>> Then please do not call it __SUB__.
>>
>> What would be the difference with (caller(0))[3] ?
>>
>
>
> Because the latter doesn't work?
>
> $ perl -wE '$f = sub {say "Hello"; (caller (0)) [3] -> () if @_}; $f -> (1)'
> Hello
> Undefined subroutine &main::__ANON__ called at -e line 1.
> $
>
> (caller (0)) [3] requires an entry in the symbol table - which not every
> sub has.
Right. __SUB__ would have to resolve as a coderef, otherwise the point
FC made about recursive closures would be lost.
The whole idea is to have a non-refcount incremented identifier that
resolves to a reference to the currently executing subroutine.
Its principle advantage would be that it would allow us to have
recursive closures without the incredibly ugly hack workaround that is
required to use such a thing without memory leaks, and which almost
nobody knows how to do right.
Johan: do *you* know how to create a recursive closure that does not
involve a memory leak or flushing the subname/method cache? Even if
you do, how many other programmers do you think know the recipe?
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next