develooper Front page | perl.perl5.porters | Postings from September 2011

Re: Perl 5.16 and Beyond.

Thread Previous | Thread Next
From:
John Imrie
Date:
September 14, 2011 12:06
Subject:
Re: Perl 5.16 and Beyond.
Message ID:
4E70FB3E.60609@virginmedia.com
On 14/09/2011 15:49, Aristotle Pagaltzis wrote:
> * John Imrie<j.imrie1@virginmedia.com>  [2011-09-14 02:25]:
>> The inner most hash should be magical so you can do
>> $features{say}{say}->('This is from feature say, no matter
>> where it's implemented');
> What do you do with the `unicode_string` feature?
>
> What about features that enable changes in parsing?
>
> What if we get some sort of coroutines or CPS in core, or some
> other change in fundamental semantics somewhere?
>
> This proposal will and can only work for the simplest kind of
> feature.
You're right, this only deals with the keyword producing features. I was 
writing this about 1am local time, so was not thinking at my best. The 
reason I came up with it was it tied into another thread that was 
worried about how to split stuff from the core and I saw this and the 
feature::where() function as a way to seamlessly move stuff out of the core.
>
> * John Imrie<j.imrie1@virginmedia.com>  [2011-09-14 01:35]:
>> use latest;
>> my @features = latest::features;
>> die "no given/when" unless grep {$_ eq 'switch'} @features
> The following would work just as well:
>
>      use latest;
>      use feature 'switch';
>
>
That would only work if you could grantee that the Perl binary 'latest' 
actually implemented feature 'switch'
With my code you could have your own module or probe for a compatible 
feature at runtime.

John

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