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

Re: Perl 5.16 and Beyond.

Thread Previous | Thread Next
From:
Abigail
Date:
October 6, 2011 12:14
Subject:
Re: Perl 5.16 and Beyond.
Message ID:
20111006191416.GA10089@almanda
On Mon, Sep 19, 2011 at 11:49:53AM +0100, Nicholas Clark wrote:
> tl;dr:
> 
> I like the plan. But the devil will be in the details.
> 
> It's a complex trade off between short, medium and long term
> maintainability, and I don't think that this approach has been taken
> by any comparable project.
> 
> On Tue, Sep 13, 2011 at 01:23:17PM -0600, Karl Williamson wrote:
> > On 09/12/2011 10:28 AM, Jesse Vincent wrote:
> > > If there is no "use v5.xx" line at the top of the code, the runtime
> > > should act as it did on v5.14 without a use v5.14 line.
> > 
> > Does that mean that without a 'use' line that the Unicode version will 
> > be the one that is in 5.14?
> 
> Based on the default of
> 
>     If there is no "use v5.xx" line at the top of the code, the runtime
>     should act as it did on v5.14 without a use v5.14 line.
> 
> then yes, I'm also assuming that the intent is that "runtime should act"
> also means that the behaviour of Unicode should be the same.


And that, I believe, is what we really, really, should *not* want.

Say, I'm using subs Foo::foo and Bar::bar. Both take a string as argument,
and as an intermediate step, they apply operation 'X' on it; where 'X'
uses some Unicode behaviour.

Do we really want Foo::foo and Bar::bar get different results after applying
X, just because one was written in 2011 (when 'use 5.14' was the hot thing),
and the other a year later (and hence has 'use 5.16')?


IMO, that leads to subtle, hard to debug issues - which then will be declared
to be not-a-bug, as it's working as p5p intended.

Maybe perl will be more maintainable, but I don't think Perl programs 
become more maintainable that way.


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