打破向后兼容性 - 好还是坏？ [英] Breaking backwards compatibility - good or bad?

问题描述

如果您有任何PHP脚本在当前版本中不起作用

由于向后兼容性中断，请查看
http://www.tonymarston.net/php-mysql...verything.html 并且看看是否

你同意我的意见。


Tony Marston
http://www.tonymarston.net

解决方案

< blockquote> ....添加对goto的支持。 ....

* AAAAAAAAAAAAAARRRGGGHHHHH！*


人们怎么能用面向对象的语言来匹配它？大多数

具有goto语句的面向对象的laguages只将它作为一个古老的剩余的

。用更清洁版的

语言清理的东西。不要把它放进去！

让我澄清一下：

在面向对象的语言中，你有两个独立的轴。

控制软件修改。 "控制"这意味着您在不引入现有软件中的错误的情况下更改了

软件：

- 开放封闭原则（第一轴）。 软件应开放给

扩展，但不接受修改。在OO语言中，这是通过继承实现的
。如果你想修改某些东西，你可以从现有的类继承而不是破坏它。所以你不会在现有代码中引入新的错误。

- 重构（第二轴）。结构改变了重构，

但不是行为。并且在每一个小步骤中测试（使用自动测试，称为

单元测试）。因此，您不会在现有代码中引入新的

错误，因为您在组件和

函数的基础上进行了测试。


如果有一件事使简单的重构变得过于困难，那么它就是goto语句和伪装的goto语句，例如return。 （=

转到结尾）。


但是对你的评论作出反应：

如果你想让PHP被视为更多而不是一种玩具语言
那么你必须停止表现得像个暴躁的孩子。
和微软一样，他们介绍了VB .NET吗？

PHP4和5之间的兼容性远远好于Visual Basic和VB .NET之间的兼容性。在

的事实上，我没有遇到一个拒绝在PHP5下运行的函数或声明

。

你没有改进语言，你杀了它。
相反。在我看来，PHP可能更严格*更严格。我喜欢

PHP 5中的类型提示，因为它在

参数检查中为我节省了大量的工作量。如果你遵循按合同设计，你要么接受一个参数作为有效参数并对它做一些事情或拒绝它。我遇到的大多数遗留代码只是接受任何东西，希望它不会爆炸.b
爆炸。呸。我甚至不喜欢自动字符串数字转换。

如果我将一个字符串传递给一个数字函数，那么我的代码基本上会出现一些问题

。我不希望用

语言掩盖，我希望得到一个不错的错误信息。 *当然* foreach

如果通过了数组以外的其他东西就会出错！

...这意味着你的数量超过了...
你不要跟我说话。我的提供程序同时支持PHP4和PHP5，并且我只需要及时获得
即可进入PHP5。唉，在我的工作中他们仍然使用

PHP4。它在OO功能方面迈出了一大步。而且，无论你喜欢与否，这都是他们的产品。你不是负责人。您可以免费开始自己的开源项目。
你怎么会喜欢它？

有人开始喊你甚至不允许自己运行你的项目吗？

...请注意'打破现有功能''不在该列表中出现
。
时间变化。和它一起生活。 Acient DOS程序不能在

Windows下运行。很多Windows 3.1驱动程序对Windows 95完全没用。

AutoCAD的ENDSV命令现在只给出一条错误消息：Discontinued

command。这是一个_awfully_向后兼容的程序。 Java有很多不赞成的价值。方法。即使你的电脑关闭也可能会启动一个关闭序列而不是断开电源。你每天都必须生气。

哦，我不期待更新。如果有一个

，我也不会感到惊讶，但我似乎并不需要它。对于Windows 98，VB6或旧版本的旧程序，我不希望更新

。同样，

我不希望PHP4的更新。甚至不是5.但是即使PHP

制造商都是人类，也可能有一些。

请注意，删除未记录的功能只能是合理的......
没有人必须证明副作用的改变是正确的。未记载的功能

是副作用。

无证件功能已经并且一直没有任何保证。这意味着你永远不会被允许修复

错误！

客户永远是对的
Thanx。我知道我是。 ;）

哦，你在谈论自己？那么，有很多* B $ *的客户，所以客户也是如此。不存在。如果他这样做了，那就是taylor

制作软件而你可以拿起电话。

...提供优雅编码的解决方案，或技术上的支持>纯粹的解决方案，是次要的。
过去20年你去过哪里？在80年代，我们编程了如此计算机可以理解它。现在我们编程所以您的计算机*和

您的同事*可以理解它。代码越来越大，而且b / b
很少被一位与

公司待在一起30年的孤独的黑客所写。易读性就是一切。

所以，PHP制造商，如果你正在读这个：

拜托，拜托，请*，请*从未来放弃三元运营商

PHP版本！只需阅读我遇到的遗留代码就可以了。

了解原因。
如果它没有破坏，就不要修复它。
再说一次，你在过去的20年里去过哪里？如果声明没有，那么b $ b似乎被执行，因为它沉默了任何错误的情况，你

有一段时间发现错误。由于不严格，PHP代码很难阅读

。当我看到一个参数初始化为

FALSE时，我认为它是一个布尔值。我的意思是，初始化也是

文档。无论你在哪里使用，都可以在编辑器中看到参数

。但它可能是一个数组，一个字符串，或其他什么。但是FALSE不会打破代码。您可以使用您传递的参数类型编写巧妙运行的怪异代码

。现在代码难以辨认的不是你的同事可以清楚地看到的，*因为它很糟糕*。并且，*是，它需要

将被固定*。


抱歉让您失望。


Best问候
to**@marston-home.demon.co.uk 写道：如果你有任何由于向后兼容性中断而无法在当前版本中运行的PHP脚本然后看看
http://www.tonymarston.net/php-mysql...verything.html ，看看你是否同意
我的意见与否。

Tony Marston
http：// www .tonymarston.net

2005年12月20日06:45:14 -0800，到** @ marston-home.demon.co.uk 写道：

如果你有任何PHP脚本将由于背部断裂而无法在当前版本中工作然后看看
http ：//www.tonymarston.net/php-mysql...verything.html ，看看你是否同意我的意见。


100％不同意。 PHP5中的变化已经很长*

即将到来，并且需要PHP中非常重要的任何内容。


评论你的意见：

当你说''正确''语言时，你的意思是你习惯的语言。但是为什么要改变PHP的语法以适应少数人的偏好？

PHP语法基于C和C ++ - 它是'并不是真的有它'

自己的语法。 PHP中的每个语法元素都以某种方式借用其他语言的
。我真的不确定你在这里争论什么

。


删除已弃用或重复的功能可能听起来不错/>
想法，但如果这些功能中的任何一个仍被广泛使用，那么它们应该单独留下
。


已弃用

（adj。）通常用于引用计算机语言来表示将使语言无效的

命令或语句

或者在将来的版本中已经过时。


BY定义不应该删除不推荐使用的函数 - 这就是为什么

首先被弃用了！也许你应该为较少的弃用函数争论

否则我认为你错过了这个词的意思

。在任何情况下，已弃用的函数应该在从语言中删除之前发出几个版本的警告

给予

人们有足够的时间来删除它们。


而不是浪费时间在不必要的清理上。对于现有客户来说，只需加工就可以实现的操作......


清理操作可以帮助新用户并帮助整体实现

维护用该语言编写的代码。一个不变的新手

问题是一个人应该使用ereg还是preg！ PHP代码可以是

充满了对不同函数的调用，这些函数几乎完全相同

但却略有不同（使用维护头痛和

微妙清理是为了使语言更简单。

all。简单的语言=优秀的语言。


删除函数别名除了烦人的用户外什么都不做。


它会增加文档和混淆。别名应该是不推荐使用
，为多个版本发出警告，然后删除。

这是一个相对简单和无痛的过程 - 它是为了搜索和替换

for godsakes。


如果它可以检测出某些应用程序代码错误的地方，并且

可以解决它而不是完全拒绝它，那么这应该是

实现的。


Bzzzt。错了。没有比使用语言更多的错误

默默地做一些事情

中最难发现的单个错误PHP是一个变量拼写错误 - 而不是错误你

默默地创建一个新变量和你想要的变量改变

不变。你想为PHP程序添加更多的无声错误吗？！？


最近出现的一个最大的问题是由''修复''导致的

拒绝错误使用引用。


哦是的。我最近遇到过那个。由于这个原因，我不得不修复我的

软件中的几个错误。我甚至没有注意到这些错误中的某些功能是错误的，直到错误出现 - 确定它们有效，但是它们没有b $ b并没有正确。通过任何想象力。


重点是，如果有一个解决方案可以解决

内存损坏而不会破坏成千上万的现有内存脚本..."


PHP团队非常努力地不破坏CORRECT脚本。不合理

脚本应该被打破，因为问题始终是

脚本而不是语言 - 它只是语言没有检查

那个问题。我使用过引用的任何地方都正确地在最新版本的PHP4上工作了

。


"我应该用数组初始化变量的想法（）

在使用任何数组函数之前是一个愚蠢的想法。现有的

代码将空值和空数组视为同一个东西，

并且在userland中必须有无数的代码行

依赖于这种行为。


不幸的是null和Array（）在

中无法互换，否则我会同意您。问题是

你最终会得到更多无声的错误，这些错误使得整个脚本不太可靠。如果我可以选择以如此简单的方式破解向后兼容性

或者降低用PHP编写的所有

脚本的可靠性，那么选择非常简单。


静态类型语言可能会坚持将变量'的类型设置为

，然后才可以通过只能在

该类型的变量，但动态类型语言没有。


我们不是在谈论变量的类型 - 我们''重新谈论

变量值的类型。你不能在数组（或不包含数字的字符串）上调用number_format（）

为什么你要为b
$ b能够调用数组函数在非阵列？函数关心

传递给它们的变量类型 - 这一直是真的！


我不必将变量声明为在使用

数字函数之前使用数字


但值仍然必须是数字!!!


引入goto语句并不是一个好主意。


同意。并且它看起来不像goto运动在任何地方

（没有双关语意）。


"引入变量和函数的区分大小写名字已经

总是让我觉得这是整个历史上最糟糕的决定

of computing。


我曾经同意你 - 作为一名Visual Basic程序员，我从来没有理解为什么有人会因为案件敏感而无法使语言变得混乱。但是，Visual Basic（甚至是DOS的QBasic）具有

a功能，它确实使它们不区分大小写 - 无论是什么情况你输入的变量是什么？会自动将它转换为它声明的情况。所以在Basic代码中，你从来没有像foobar，FooBar和FOOBAR这样的变量 - 它始终是一致的。


区分大小写的情况是一致性。我不想要我的代码

与所有不同类型的套装变量一起使用同样该死的

名称。我希望它是一致的。在这种情况下有错误吗

a好东西。


我在大型机上遇到的操作系统都没有，

我在过去30年使用的迷你电脑和个人计算机系统已经区分大小写，也没有任何编译器（除了PHP和b
）它的变量名称），文本和文档编辑器，以及

数据库查询工具。


到底是怎么回事？！？区分大小写的变量/函数存在于C，C ++，

Java，C＃，Pascal，Delphi，Javascript，PERL，Ruby，Python，Smalltalk，

Objective-C和等等。 Unix中的大部分内容都区分大小写

包括文件系统。我不确定你在过去30年里为了什么做了什么，但绝大多数的计算机世界都是区分大小写的。你已经离开了。


你能说出一个引入区分大小写的单一问题

是解决方案吗？ br />

一致性。


声称

SAME WORD的大小写的每个组合都有一个不同的意思，你实际上是在打开自己

up ..."


我同意。但是，当你甚至有两个变量或函数具有相同的名称而且仅在

情况下变化时，问题非常罕见。一般情况下，区分大小写实际上用于强制执行单个语言单词的单个拼写。我更愿意你不能用b $ b重新声明一个具有相同名称但差异很大的变量/函数

case但却无法使用变量/ function除非你使用

案例，否则我们都会对此感到高兴。

< blockquote>我想我不是唯一一个对PHP

的发展方向感到不满的人。这是一个超越向后兼容性的更大问题。我认为这是两种观点之间的冲突：一位学者与一位

的工程师。工程师发现问题并尝试解决问题。

结果是重要的，而美学和原则是次要的。

正如我的教授曾经说过的那样，不要问你为什么要做某事，但你怎么做？ />
这样做。另一方面，学者寻求他的同行的认可和b $ b批准。当

的主要目标是给人留下深刻印象时，实际意义是无关紧要的。


越来越多的学者赢得了这场斗争。

If you have any PHP scripts which will not work in the current releases
due to breaks in backwards compatibility then take a look at
http://www.tonymarston.net/php-mysql...verything.html and see if
you agree with my opinion or not.

Tony Marston
http://www.tonymarston.net

解决方案

.... Add support for goto. ....
*AAAAAAAAAAAAAARRRGGGHHHHH!*

How can anyone match that with an object-oriented language? Most
object-oriented laguages that have a goto statement only have it as an
ancient left-over. Something to clean out in a cleaner version of the
language. NOT to put it in!
Let me clarify:
In an object-oriented language, you have two independent "axes" of
controlled software modification. "Controlled" meaning that you change
software without introducing bugs in existing software:
- The Open Closed Principle (first axis). "Software should be open to
extension, but closed to modification". In OO languages, this is
implemented through inheritence. If you want to modify something, you
can inherit from an existing class instead of breaking it. So you don''t
introduce new bugs in EXISTING code.
- Refactoring (second axis). The structure is changed with Refactoring,
but not the behaviour. And this is tested (with automated tests, called
"unit tests") in every single little step. So you don''t introduce new
bugs in existing code because you test it thouroughly on component and
function basis.

If there is one thing that makes simple refactorings overly difficult,
it is goto statements and disguised goto statements like "return" (=
goto end).

But in reaction to your comment:

If you want PHP to be considered as more than a ''toy'' language
then you must stop behaving like petulant children. Like Microsoft when they introduced VB .NET? The compatibility between
PHP4 and 5 is far, far better than between Visual Basic and VB .NET. In
fact, I did not encounter one function or statement yet that refused to
run under PHP5.
You are not improving the language, you are killing it. On the contrary. PHP could be a *lot* more strict in my opinion. I like
the type hinting in PHP 5, as it saves me a *huge* amount of work in
parameter checking. If you following "design by contract", you either
accept a parameter as valid and do something with it or reject it. Most
legacy code I encounter just accepts anything and hopes it does not
explode. Yuck. I even don''t like the automatic string-number conversion.
If I pass a string to a numeric function, there''s something
fundamentally wrong with my code. I don''t want that covered up by the
language, I want to get a decent error message. *Off course* foreach
should give an error when something other than an array is passed!
... That means that you are outnumbered ... You don''t speak for me. My provider supports both PHP4 and PHP5 and I
came in time to get into PHP5 only. Alas, at my work they still use
PHP4. It is taking a giant step back in OO functionality. And, wether
you like it or not, it''s their product. You are not in charge. You are
free to start your own open source project. How would YOU like it when
somebody starts shouting you are not even allowed to run your own project?
... Please notice that ''breaking existing features'' does NOT appear
in that list. Times change. Live with it. Acient DOS programs do not run under
Windows. Lots of Windows 3.1 drivers are totally useless for Windows 95.
AutoCAD''s ENDSV command now only gives an error message: "Discontinued
command". And THAT''s an _awfully_ backwards compatible program. Java has
lots of "deprecated" methods. Even the off-switch of you PC may start a
shutdown sequence instead of just disconnecting the power. You must be
angry every day.
Oh, and I don''t expect an update. I''m not surprised if there is one
either, but I don''t require it as you seem to do. I don''t expect updates
for Windows 98, VB6 or whatever old versions of old programs. Likewise,
I don''t expect updates for PHP4. Not even for 5. But as even the PHP
makers are human, there may be some.
Note here that the removal of undocumented features can
only be justified ... No one has to justify a change in a side effect. Undocumented features
are side effects. There is and has never been any guarantee about
undocumented features. It would mean that you were never allowed to fix
bugs!
The customer is always right Thanx. I know I am. ;)
Oh, you were speaking about yourself? Well, there are a *LOT* of
customers, so "the customer" does not exist. If he did, it was taylor
made software and you could just pick up the phone.
... Providing an elegantly-coded solution, or a technically
pure solution, is secondary. Where have you been for the last 20 years? In the 80s, we programmed so
the computer could understand it. Now we program so your computer *and
your colleague* can understand it. Code has grown larger and larger and
is rarely written anymore by one lonely hacker who stays with the
company for 30 years. Legibility is everything.
So, PHP makers, if you are reading this:
Please, please, please, *PLEASE* drop the ternary operator from future
PHP versions! Just read the legacy code I''m confronted with and you
understand why.
If it ain''t broke, don''t fix it Again, where have you been in the last 20 years? If a statement does not
appear to be executed because it "silences" any error condition, you
have a hell of a time finding bugs. PHP code can be very hard to read
because of its un-strictness. When I see a parameter initialised as
FALSE, I assume it is a boolean. I mean, the initialization is also
documentation. You see the parameters in your editor wherever you use
them. But it may be an array, a string, or whatever. But FALSE will not
break the code. You can write monstrous code that coincidentally works
with the parameter types you pass. Now code that is illegible is not
legible by your collegue either, *SO IT IS BROKE*. And, *YES, IT NEEDS
TO BE FIXED*.

Sorry to disappoint you.

Best regards
to**@marston-home.demon.co.uk wrote: If you have any PHP scripts which will not work in the current releases
due to breaks in backwards compatibility then take a look at
http://www.tonymarston.net/php-mysql...verything.html and see if
you agree with my opinion or not.

Tony Marston
http://www.tonymarston.net

On 20 Dec 2005 06:45:14 -0800, to**@marston-home.demon.co.uk wrote:

If you have any PHP scripts which will not work in the current releases
due to breaks in backwards compatibility then take a look at
http://www.tonymarston.net/php-mysql...verything.html and see if
you agree with my opinion or not.
100% disagree. The changes in PHP5 have been a *very* long time
coming and are needed to anything really big and useful in PHP.

Comments on your comments:
When you speak of ''proper'' languages you mean ''languages that you are used to''. But why should the syntax of PHP be changed just to suit the preferences of a few individuals?

The PHP syntax is based on C and C++ -- it''s doesn''t really have it''s
own syntax. Every syntax element in PHP is borrowed, in some way,
from other languages. I''m really not sure what you''re arguing against
here.

"Removing deprecated or duplicated functions may sound like a good
idea, but if any of those functions are still widely used then they
should be left alone."

Deprecated
(adj.) Used typically in reference to a computer language to mean a
command or statement in the language that is going to be made invalid
or obsolete in future versions.

BY DEFINITION Deprecated functions should be removed -- that''s why
there are deprecated in the first place! Maybe you should be arguing
for less deprecated functions otherwise I think you miss the meaning
of the word. In any case, deprecated functions should issue warnings
for a few versions before they are removed from the language giving
people plenty of time to remove them.

"Instead of wasting time on unnecessary "clean-up" operations which
will achieve nothing but aggravation for existing customers..."

The cleanup operations help new users and help with the overall
maintainence of code written in the language. A constant newbie
question is whether one should use ereg or preg! PHP code can be
filled with calls to different functions which do nearly the same
thing yet are subtly different (ausing maintainence headaches and
subtle bugs. The cleanup is meant to make the language simpler for
all. Simple language = good language.

"Removing function aliases does nothing except annoy users."

It increases the documentation and the confusion. Aliases should be
deprecated, warnings issued for several versions, and then removed.
It''s relatively simple and painless process -- it''s search & replace
for godsakes.

"If it is possible to detect where some application code is wrong and
work around it instead of rejecting it completely, then this should be
implemented."

Bzzzt. Wrong. Nothing causes more bugs than having a language
silently do something unintented. The hardest single bug to find in
PHP is a variable typo on assignment -- instead of an error you
silently create a new variable and the variable you intended to change
goes unchanged. You want to add more silent errors to PHP programs?!?

"One of the biggest recent problems has been caused by a ''fix'' which
rejects the incorrect usage of references."

Oh yes. I recently came across that. I had to fix several bugs in my
software due to that. I never even noticed how wrong some of these
functions were until that error came up -- sure they worked, but they
weren''t "correct" by any stretch of the imagination.

"The point is that if a solution is available which will resolve the
memory corruption AND not break thousands of existing scripts..."

The PHP team tries very hard not to break CORRECT scripts. INCORRECT
scripts should be broken because the problem was always with the
script and not the language -- it''s just the language didn''t check for
that problem. Anywhere that I had used references correctly worked
perfectly on the newest version of PHP4.

"The idea that I should have to initialise a variable with array()
before using any array functions on it is a stupid idea. The existing
code treats a null value and an empty array as one and the same thing,
and there must be countless lines of code out there in userland which
rely on this behaviour."

Unfortunately null and Array() are not interchangable everywhere in
the language otherwise I would agree with you. The problem is that
you end up with more silent unintented bugs making scripts overall
less reliable. If I have a choice in breaking backwards compatibility
in such a simple-to-fix way or decreasing the reliablity of all
scripts written in PHP, the choice is pretty simple.

"Statically typed languages may insist that a variable''s type is set
before it can be accessed by functions that will only work on a
variable of that type, but dynamically types languages do not."

We''re not talking about the type of variable -- we''re talking about
the type of the value of the variable. You can''t call number_format()
on an array (or a string that doesn''t contain a number) why should you
be able to call array functions on non-arrays? Functions care about
the types of variables passed to them -- this has always been true!

"I do not have to declare a variable as being numeric before using a
numeric function on it"

But the value still has to be a number!!!

"Introducing the goto statement is not a good idea."

Agreed. And it doesn''t look like the goto movement is going anywhere
(no pun intended).

"Introducing case-sensitivity for variables and functions names has
always struck me as the worst possible decision in the entire history
of computing."

I used to agree with you -- as a Visual Basic programmer I never
understood why anyone would bother to clutter up the language with
case-sensitivity. However, Visual Basic (and even QBasic for DOS) had
a feature that really made their case-insensitivity work -- no matter
what case you typed the variable in, it would automatically convert it
to the case it was declared in. So in Basic code, you never had
variables like foobar, FooBar, and FOOBAR -- it was always consistent.

The case for case-sensitivity is consistency. I don''t want my code
litered with all different kinds of cased variables with the same damn
name. I want it to be consistent. Have it error out in that case is
a good thing.

"None of the operating systems I have encountered on mainframe,
mini-computer and personal computer systems I have used in the past 30
years has been case-sensitive, nor has any of the compilers (apart
from PHP and its variable names), text and document editors, and
database query tools."

What the hell?!? Case-sensitive variables/function exist in C, C++,
Java, C#, Pascal, Delphi, Javascript, PERL, Ruby, Python, Smalltalk,
Objective-C and so on. Most everything in Unix is case-sensitive
including the file system. I''m not sure what you''ve been doing for
the past 30 years but the vast majority of the computing world is
case-sensitive. You''re out of the loop.

"Can you name me one single problem where introducing case-sensitivity
was the solution?"

Consistency.

"By claiming that each combination of upper and lower case for the
SAME WORD has a different meaning you are actually opening yourself
up..."

I agree. However, the problem is exceedingly rare when you ever even
have two variables or functions with the same name that vary only in
case. Generally case-sensitivity is in fact used to enforce a single
case spelling of a language word. I''d prefer that you couldn''t
redeclare a variable/function with the same name but with a difference
case and yet not be able to use a variable/function unless you use the
case it was declared with -- I think we''d both be happy with that.

I guess I''m not the only one who''s unhappy about the direction that PHP
is going. It''s larger issue that goes beyond backward compatibility. I
see it as a conflict between two points of view: an academic''s vs. an
engineer. An engineer sees a problem and tries to solve it. The
outcome is what matters, while aesthetics and principles are secondary.
As my professor used to say, "Ask not why you do something, but HOW you
do it." An academic, on the other hand, seeks the recognition and
approval of his peers. Practical implications are irrelevant when the
main objective is to impress.

More and more, the academic is winning the fight.

这篇关于打破向后兼容性 - 好还是坏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！