Backporting Features

| 6 Comments

One current discussion on p5p is the namespace of fixed versions of reftype(), refaddr(), and blessed(), recently added to bleadperl.

These functions are part of Scalar::Util right now. Unfortunately, they return undef for non references. This leads to code like:

my $ref_type = reftype( $maybe_ref );
do_something_with_ref( $ref_type ) if defined $ref_type;

(If you don't follow all of the reasons why you have to do that, that's good; you haven't imagined all of the odd and strange ways people might name their classes in various parts of the Perl 5 internals and DarkPAN modules. Safety dictates finding these corner cases.)

Anyhow.

Making these fixed functions available in the core without having to load Scalar::Util offers some advantages but also some disadvantages. It's the "You can't add new keywords to Perl 5" problem. What if someone else defined functions of that name?

Worse, what if someone loads Scalar::Util and imports its functions and expects those semantics instead of the new semantics?

(Apparently it's impossible to detect the declaration or importation of symbols with conflicting names so as to produce warnings or exceptions in this case, though I don't see why. If we were in the habit of declaring the version of Perl 5 our code uses, we wouldn't have these problems.)

The discussion inevitably circled back to the ineffable question of "If this new feature is going in the core, how do people use it in previous releases of Perl 5?" That is, "You've added a new feature to Perl 5 which will be in Perl 5.14 released next year. Is there any way to backport that feature to Perl 5.12? How about Perl 5.10? You know, RHEL 3 is still around. Why do you hate Perl .5.8?"

At some point the weight of ensuring that code written for a future version of Perl 5 can run correctly (if you cram in enough flying buttresses of CPAN shims) on code written for obsolete versions of Perl 5 will pull down the entire edifice. Allowing code written for previous versions of Perl 5 to run on modern versions unmodified (or with a simple use 5.10; at the top—I know a great combination of find and sed which can perform this kind of textual manipulation {and if you're on Windows, use PPT to get portable versions of these tools}) is often good and useful.

Going the other way... well, I don't understand it. If it's possible and someone wants to do it, fine. Why should it block improving the next release of Perl 5 though?

6 Comments

Breaking some backcompat in minor releases seems to be par for the course. I've experienced this with Perl 5.10 vs 5.8 and Apache 2.2 vs 2.0.

Are you thinking of binary compatibility? Upgrade guides explicitly disclaim binary compatibility between major releases such as 5.8.x to 5.10.x.

The main non-backcompat issue I saw with 5.10.x was that $#{@$arrayref} no longer worked. Now, it's much better to use $#$arrayref, but it still meant going back to change previously working code.

What does it not allowed adding keywords.
Too bad-- i like using keyword instead,
its easier for me.

There's no real namespace distinction between keywords and user-defined functions. If you add a keyword with the same name as someone's user-defined function, you can break their code in odd ways if they run it on a new version.

Your time writing a reply was wasted, you fell for a cheap spammer trick. Check the link.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on August 30, 2010 11:49 AM.

Mechanism versus Policy was the previous entry in this blog.

What's Going Right in Perl is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?