Bug #49827 for enum: enum should create true constants

Fri Sep 18 23:29:37 2009 chip [...] pobox.com - Ticket created

Subject:

enum should create true constants

Modulo issues of safe syntax, *{"$pkg$prefix$_"} = sub () { $n }; should be *{"$pkg$prefix$_"} = eval "sub () { $n }"; The speed difference will not be trivial.

Sat Aug 24 15:47:44 2013 NEILB [...] cpan.org - Correspondence added

Hi Chip, I'm guessing things have been improved in Perl in the 4 years since you submitted this. When I benchmark the two approaches I get negligible difference between them, which makes me think that the optimiser now treats them the same? Either that or I've bungled my benchmark :-) I've been testing with 5.16.3. Here's my benchmark: use Benchmark; BEGIN { *{'SLOW'} = sub () { 41 }; *{'FAST'} = eval "sub () { 42 }"; } timethese(1000000000, { 'b eval' => sub { my $x = FAST }, 'a non-eval' => sub { my $x = SLOW }, });

Sat Aug 24 15:47:44 2013 The RT System itself - Status changed from 'new' to 'open'

Tue Oct 01 05:22:50 2013 NEILB [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Oct 01 05:22:56 2013 NEILB [...] cpan.org - Fixed in 1.05 added

Tue Oct 01 16:58:39 2013 chip [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #49827] enum should create true constants
Date:	Tue, 01 Oct 2013 13:58:12 -0700
To:	bug-enum [...] rt.cpan.org
From:	Chip Salzenberg <chip [...] pobox.com>

On 8/24/2013 12:47 PM, Neil_Bowers via RT wrote: Show quoted text

> BEGIN { > *{'SLOW'} = sub () { 41 }; > *{'FAST'} = eval "sub () { 42 }"; > }

That benchmark isn't representative because you should have a lexical $n in the SLOW case.

Wed Oct 02 08:58:20 2013 NEILB [...] cpan.org - Correspondence added

Show quoted text

> That benchmark isn't representative because you should have a lexical $n > in the SLOW case.

Can you expand on what you mean please, perhaps with code, as I've obviously not got it. I tried this: BEGIN { my $x = 42; *{'SLOW'} = sub () { $x }; *{'FAST'} = eval "sub () { $x }"; } But that's obviously not what you meant, since the eval case seems to be slightly slower with this. Thanks.