Ïðèãëàøàåì ïîñåòèòü
Æèòêîâ (zhitkov.lit-info.ru)

Chapter 7. Upgrading (Plastic Surgery)

Previous Table of Contents Next

Chapter 7. Upgrading (Plastic Surgery)

"When we inherit property, it does not occur to us to throw it away, even when we do not want it."

—Mark Twain, A Connecticut Yankee in King Arthur's Court

graphics/ch07.gif

Perl has remained extraordinarily backward compatible. The vast majority of programs written for Perl 4.018 will work identically on Perl 5.8.3. Thanks to the zealous efforts of a group affectionately—or otherwise—called the "backward compatibility police," only a handful of changes were made during that decade that could change the behavior of existing code.[1]

[1] This will not be the case with Perl 6, however. The developers concluded that backward compatibility had been taken as far as it could go, and if they wanted to realize significant gains in syntactical power, consistency, and learnability, it was time to bite the bullet.

This cozy state of affairs (how many applications today will accept a file written by a 15-year-old version of themselves?) means that a program you inherit could have been written for a truly ancient version of Perl. Or it could have been written by a programmer who was only familiar with a truly ancient version of Perl, which amounts to the same thing. As long as you're porting the program—and especially if you're rewriting it—you should take the opportunity to use the labor-saving devices available in modern Perl. So much has been added to the language that you may be able to radically simplify the code.

In this chapter I'll show you how you can tell what version of Perl a program's creator was programming to, and how you can improve it by using features in more modern versions of Perl.

    Previous Table of Contents Next