develooper Front page | perl.perl5.porters | Postings from December 2010

Re: [perl #80628] [PATCH] __SUB__

Thread Previous | Thread Next
From:
Abigail
Date:
December 13, 2010 08:47
Subject:
Re: [perl #80628] [PATCH] __SUB__
Message ID:
20101213164704.GJ29007@almanda
On Mon, Dec 13, 2010 at 05:26:29PM +0100, demerphq wrote:
> On 13 December 2010 17:09, Eric Brine <ikegami@adaelis.com> wrote:
> > On Mon, Dec 13, 2010 at 3:07 AM, Johan Vromans <jvromans@squirrel.nl> 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] ?
> >>
> >
> > caller[3] doesn't work for anon subs.
> >
> >> perl -E"sub { say( (caller(0))[3] ) }->()"
> > main::__ANON__
> >
> > It was specifically proposed that __SUB__ would return a reference in at
> > least that case.
> 
> It seen's to me that it MUST return a reference in ALL situations.

I agree. Do one thing in one case, and another in another case doesn't seem
like a win situation to me. At least, not here. You certainly shouldn't
have to change the body of a sub if you change it from an anon sub to a
named one. 

> 
> > It's more like SUPER than __FILE__ in a sense. Maybe something without
> > dashes would be more appropriate.
>

I don't think so. While "SUB" is different from "sub", I'm not very keen
to have two keywords that only differ in case. And anything else without
underscores has the same problem as any other new keyword: possible clashes.



Abigail

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About