develooper Front page | perl.perl5.porters | Postings from March 2021

Re: on changing perl's behavior

Thread Previous | Thread Next
Ricardo Signes
March 31, 2021 01:27
Re: on changing perl's behavior
Message ID:
On Tue, Mar 30, 2021, at 3:54 AM, Christian Walde wrote:
> On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <> wrote:
>>  * This one I think I can only state as a trade-off per se:  Spending time on maintaining long-discouraged behaviors is good only to the extent that they can't be deprecated and removed instead.  How do we know whether we can deprecate and remove some behavior?  Well, that's largely a function of all of the above.
> Have more reading and thinking to do, but:
> As far as i am informed this one is a red herring.

I think that *usually* when "if only we could remove X, things would be simpler" is incorrect.  The common whipping boy here is formats.  "Why can't we get rid of formats??" people cry.  "They're just taking up space!"

Well, in reality, deleting formats would not be such a big win.  Except, maybe, to reclaim the syntax that their special punctuation variables occupy.  LeoNerd was talking about (or possibly implemented?) a means to hide those variables away to free up the syntax.  Very nice!

On the other hand, there are some places that the complexity is present, and my assertion (which I'm happy to see challenged) is that the more interesting places to remove it are those where it's most difficult to remove in a safe way.  unicode_strings is one example.

At any rate:  I agree that "allow us to eject troublesome parts of the implementation" is not the major driving force for changing defaults in any way currently being floated.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About