Perl 版本中向后不兼容的一些具体示例有哪些?
从 Perl 1.0 首次公开发布(1987 年 12 月 18 日)到当前稳定版本 5.10.1(2009 年)已经过去了 22 年。
在这 22 年中,发布了以下值得注意的版本:
- Perl 1.0(1987 年 - 初始版本)
- Perl 2(1988 年 - 更好的正则表达式)
- Perl 3(1989 年 - 支持二进制数据流)
- Perl 4(1991 年 - 识别 Perl 的版本) Camel Book 中描述)
- Perl 5(1994 - 引入了重大变化,几乎完全重写了解释器)
- Perl 5.6(2000 - 64 位支持,unicode 字符串,大文件支持)
- Perl 5.8(2002 - 改进了 unicode 支持,新的 IO 实现) )
- Perl 5.10(2007 - 新的 switch 语句、正则表达式更新、智能匹配运算符)
我正在寻找 Perl 历史上向后不兼容的具体示例。
问题:
- 在 Perl 22 年的历史中,是否有任何 Perl 向后不兼容的例子,即针对 Perl 版本 X 的 Perl 源代码无法在版本 Y 下运行(其中 Y > X)?
请包括尽可能提供参考和代码示例。
It has been 22 years between the initial public release of Perl 1.0 (December 18, 1987) and the current stable release 5.10.1 (2009).
During those 22 years the following notable releases have been made:
- Perl 1.0 (1987 - initial release)
- Perl 2 (1988 - better regular expressions)
- Perl 3 (1989 - support for binary data streams)
- Perl 4 (1991 - identifying the version of Perl described in the Camel Book)
- Perl 5 (1994 - major changes introduced, near complete rewrite of the interpreter)
- Perl 5.6 (2000 - 64 bit support, unicode strings, large file support)
- Perl 5.8 (2002 - improved unicode support, new IO implementation)
- Perl 5.10 (2007 - new switch statement, regular expression updates, smart match operator)
I'm looking for specific examples of backwards incompatibilities during the history of Perl.
Question:
- In the 22 year history of Perl, are there any examples of Perl backwards incompatibility where Perl source code targeting Perl version X won't run under version Y (where Y > X)?
Please include references and code examples when possible.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
最大的故意不兼容性之一是数组插值,它在 Perl 4 和 Perl 5 之间发生了变化。
在 Perl 4 中,这将是:
在 Perl 5 中,这将是:
幸运的是,如果数组不存在,Perl 会警告您“可能的意外插值” ”。
线程在 5.005 和 5.6 之间经历了很大的变化。 “5005 个线程”使用传统的 POSIX 线程模型,其中所有全局数据都是共享的。虽然理论上这更快,因为那时 Perl 只能使用 POSIX 线程,但这对 Perl 编码人员来说是一场噩梦。大多数 Perl 模块都不是线程安全的。而且它从来没有真正发挥过作用。
在5.6中,ActiveState等人在Windows上制作了fork()。当您在 Windows 上 fork() 时,Perl 会复制解释器对象并运行两个解释器的操作码。这被称为“多重性”。
在 5.8 中,Arthur Bergman 运行了它并用它来创建 ithread。由于多重性正在模拟一个单独的进程,因此默认情况下不会共享任何数据。只有您所说共享的数据才会被共享。这使得它们使用起来更加安全,尽管 ithreads 花了很长时间才稳定下来。伊丽莎白·马泰森 (Elizabeth Mattijsen) 和杰里·赫登 (Jerry Hedden) 等人让这一切成为现实。
5005个线程最终在5.10.0中被删除。存在兼容性层,但我怀疑它是否真的可以在生产代码中工作。
另一个很大的不兼容性是 5.6 和 5.8 之间的 Unicode。 5.6 中的 Unicode 爆发了。字符串是否是 Unicode 由周围的范围决定。它在 5.8 中被完全重新设计,因此现在字符串的 Unicode 性与字符串相关联。使用 5.6 的 Unicode 编写的代码通常必须在 5.8 中重写,通常是因为要使 5.6 的 Unicode 正常工作,您必须进行丑陋的 hack。
最近,5.10.1 对智能匹配进行了一系列不兼容的更改。幸运的是,它们是在 5.10.0 中引入的,所以这没什么大不了的。那里的故事是 Perl 6 引入了智能匹配概念,并将其向后移植到 Perl 5 的开发版本。随着时间的推移,Perl 6 的智能匹配理念发生了变化。没有人告诉 Perl 5 的人,它在 5.10.0 中没有改变。 拉里·沃尔注意到并做了相当于天哪你错了!!! 新的 Perl 6 版本被认为明显更好,因此 5.10.1 修复了它。
One of the biggest deliberate incompatibilities is array interpolation which changed between Perl 4 and Perl 5.
In Perl 4 that would be:
In Perl 5 that would be:
Fortunately, if the array doesn't exist Perl will warn you about "possible unintended interpolation".
Threads underwent a big change between 5.005 and 5.6. "5005 threads" used the traditional POSIX threading model where all global data is shared. While in theory this was faster, because then Perl could just use POSIX threads, it was a nightmare for Perl coders. Most Perl modules were not thread-safe. And it never really worked well.
In 5.6, ActiveState and others made fork() on Windows. When you fork() on Windows, Perl would make a copy of the interpreter object and run the opcodes of both interpreters. This was known as "multiplicity".
In 5.8, Arthur Bergman ran with that and used it to create ithreads. Because multiplicity is emulating a separate process, no data is shared by default. Only data you say is shared is shared. This makes them much safer to use, though it took a long time before ithreads were stable. Folks like Elizabeth Mattijsen and Jerry Hedden made that happen.
5005threads were finally expunged in 5.10.0. A compatibility layer exists, but I doubt it would really work in production code.
Another big incompatibility came wrt Unicode between 5.6 and 5.8. Unicode in 5.6 blew. Whether or not a string was Unicode was decided by the surrounding scope. It was completely re-engineered in 5.8 so now the Unicodeiness of a string is tied to the string. Code written using 5.6's Unicode usually had to be rewritten in 5.8, often because to get 5.6's Unicode to work right you had to do ugly hacks.
Recently, 5.10.1 made a bunch of incompatible changes to smart-match. Fortunately they were introduced in 5.10.0 so its not a big deal. The story there is Perl 6 introduced the smart-match concept, and it was backported to a development version of Perl 5. Time passed, and Perl 6's idea of smart-matching changed. Nobody told the Perl 5 guys and it went out in 5.10.0 unchanged. Larry Wall noticed and did the equivalent of OMG YER DOIN IT WRONG!!! The new Perl 6 version was seen as significantly better and so 5.10.1 fixed it.
伪哈希是我最近想到的一个例子头脑。一般来说,perldelta 文件概述了特定版本中不兼容的更改。这些变化几乎总是晦涩难懂(如伪哈希)或很小。
Pseudo-hashes are a recent example that spring to my mind. In general, perldelta files have an overview of incompatible changes in a specific version. These changes almost always either obscure (like pseudo-hashes) or small.
是的。有很多,尽管它们通常都很小。有时这是由于弃用周期最终以删除而告终。有时这是由于新的(和实验性的)功能的语义改变所致。有时,它会修复无法正常工作的问题。 Perl 开发人员竭尽全力尽可能地保持版本之间的向后兼容性。我不记得曾经有过因升级到新版本的 Perl 而损坏的脚本。
内部哈希顺序已更改多次。虽然这不是您应该依赖的东西,但如果您无意中这样做,它可能会导致问题。
主要 (5.x) 版本之间的二进制不兼容很常见,但这通常仅意味着任何 XS 扩展都需要重新编译。
完整的列表太长,无法在此列出。您可以通过检查每个版本的历史的“不兼容的更改”部分来获取它。
Yes. There are many, although they're usually minor. Sometimes this is due to deprecation cycles ultimately ending in removal. Sometimes it's due to changing semantics for new (and experimental) features. Sometimes it's bug fixes for things that didn't work correctly. The Perl developers take great pains to preserve backwards compatibility between versions wherever possible. I can't recall ever having a script that was broken by upgrading to a new version of Perl.
The internal hash order has changed several times. While this isn't something you should depend on, it can cause problems if you unwittingly do.
Binary incompatibility between major (5.x) releases is common, but that usually just means that any XS extensions need to be recompiled.
The complete list is far too long to list here. You can get it by checking the "Incompatible Changes" section of each version's history.
OTOH,有一些可追溯到 Perl 1 的狂野功能仍然有效。例如,这打印了什么?
没错,23。为什么?因为“关联数组”在 Perl 1 中不是一等对象。
$foo{bar}
有效,但没有%foo
。我真的不知道为什么,甚至 Perl 1 手册页也承认这是疣。因此,为了与 Perl 1 兼容,您可以在不使用%
的情况下访问全局哈希,也许您的键盘坏了或者 Apple 决定没有人使用%
符号。chdir
有一些奇怪的地方。不带参数的 chdir() 会将您带到主目录,复制 shell cd 行为。不幸的是,chdir undef
和chdir ""
也会导致很难捕获chdir
周围的错误。幸运的是,这种行为已被弃用。我必须确保它在 5.14 中消失。$[
仍然存在并且未弃用,但“非常不鼓励”。它改变了数组的第一个索引,所以如果你是像我一样的人并且从 1 开始计数,你可以这样做:Perl 5 将其更改为文件范围,否则它会拖累性能,并且是一个很好的来源疯狂的。
OTOH there's some wild features dating back to Perl 1 that still work. For example, what does this print?
That's right, 23. Why? Because "associative arrays" were not first-class objects in Perl 1.
$foo{bar}
worked but there was no%foo
. I really don't know why, even the Perl 1 man page acknowledges this is warty. So for compatibility with Perl 1 you can access a global hash without using a%
, maybe if your keyboard is broken or Apple decides nobody uses the%
symbol.chdir
has some oddities.chdir()
with no argument will take you to your home directory, replicating the shellcd
behavior. Unfortunately so willchdir undef
andchdir ""
making it difficult to catch errors aroundchdir
. Fortunately this behavior is deprecated. I will have to make sure it dies in 5.14.$[
is still around and remains undeprecated, but "highly discouraged". It changes what the first index of an array is, so if you're a human like me and count from 1 you could do:Perl 5 changed it to be file-scoped, as otherwise it was a performance drag and a great source of CrAzY.
我在 Perl4 和 Perl5 中遇到了一些奇怪的错误,以不同的顺序评估作业的左侧和右侧,引用 Perl 陷阱给粗心的人:
对于一些新的和可能不兼容的内容,请参阅常见问题解答< /a> Perl4 和 Perl5 之间。
I've had some funky errors with Perl4 and Perl5 evaluating left hand and right hand sides of an assignment in a different order, quoting the Perl traps for the unwary:
For some new and possibly incompatible stuff, see the FAQ between Perl4 and Perl5.