Breaking backwards compatibility - good or bad?

[tony]

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

[Dikkie Dik]

.... Add support for goto. ....
*AAAAAAAAAAAAAA RRRGGGHHHHH!*

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: "Discontinu ed
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.u k 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

[Wayne]

On 20 Dec 2005 06:45:14 -0800, to**@marston-home.demon.co.u k 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!!!

"Introducin g the goto statement is not a good idea."

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

"Introducin g 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.

[Chung Leong]

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.

[Default User]

Wayne wrote:

"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

I disagree with this. As deprecated elements may be removed, no new
code should be written that uses them. However, if removal of the
deprecated construct will cause significant breakage of existing code,
then an overriding reason should be present for immediate removal.

Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Oli Filth]

Default User said the following on 20/12/2005 22:36:

Wayne wrote:

"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

I disagree with this. As deprecated elements may be removed, no new
code should be written that uses them. However, if removal of the
deprecated construct will cause significant breakage of existing code,
then an overriding reason should be present for immediate removal.

But by that argument, deprecated features would *never* *ever* get
removed, and so rendering the term "deprecated " redundant.

--
Oli

[Oli Filth]

Chung Leong said the following on 20/12/2005 21:52:

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.
Engineering isn't just about finding the first thing that works, it's
about finding the best solution given particular constraints, and
hopefully thinking about aspects such as long-term maintenance as well.

Normally, it might be true that aesthetics and principles are secondary,
but in the case of a computer language, these two qualities are often
intrinsically related to the semantics, structure and useability, and so
can't be ignored. Ignoring them is what led to PHP 4.

(Note that I'm not saying that backwards compatibility isn't important.)

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.

PHP is *never* going to win recognition as some clever, beautifully
thought-out, academic language, so I think that saying "the academic is
winning the fight" is somewhat erroneous - I don't think that's what the
developers are trying to do (not as a main priority, anyway).

I think the developers have realised, however, that there are millions
of programmers out there who are used to OO features (for example) in
more "structured " languages, but laughed at PHP 4's attempt at OO, and
still laugh at the mish-mash nonsense of inconsistency that litters PHP
5. To attract these hardened programmers who are used to the formalities
of, for instance, Java, and view PHP as a toy not to be used for any
serious purpose, the developers know that from now on, the future of PHP
needs to be *planned* rather than *hacked*, and some of the embarrassing
legacy swept under the carpet.

Unfortuantely (well, maybe not, depending on your opinion), that may be
at the expense of the "PHP is great for hacking together any old
unprogrammatic atrocity" ethos. But then again, that ethos is the
self-fulfilling prophecy that fosters the liberal use of eval(),
numbered variables rather than arrays, dynamic class definitions, code
replication and nested-ifs instead of polymorphism, etc., etc...

To properly design a language, it necessarily involves a large amount of
"academic" input - in the sense that it involves sitting down for a
*long* time and working out the whole plan in fine detail.

--
Oli

[Default User]

Oli Filth wrote:

Default User said the following on 20/12/2005 22:36:

Wayne wrote:

"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

I disagree with this. As deprecated elements may be removed, no new
code should be written that uses them. However, if removal of the
deprecated construct will cause significant breakage of existing
code, then an overriding reason should be present for immediate
removal.

But by that argument, deprecated features would never ever get
removed, and so rendering the term "deprecated " redundant.

How do you figure? There has be a review of the benefits versus
detriments. Conversely, if all deprecated elements are removed
immediately, there's also no need for the term.

Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Wayne]

On 20 Dec 2005 23:45:13 GMT, "Default User" <de***********@ yahoo.com>
wrote:

But by that argument, deprecated features would never ever get
removed, and so rendering the term "deprecated " redundant.
How do you figure? There has be a review of the benefits versus
detriments.

Obviously the review has already been done on depreciated elements
hence why they are depreciated. If there is no reason to remove them
at all, they wouldn't be depreciated!
Conversely, if all deprecated elements are removed
immediately, there's also no need for the term.

Agreed. Depreciated is the stage before the item is to be removed --
to give everyone time to stop using it (and to prevent new people from
using it). Once you've given everyone enough time to stop using it,
you remove it. I don't see the problem here.

[Default User]

Wayne wrote:

On 20 Dec 2005 23:45:13 GMT, "Default User" <de***********@ yahoo.com>
wrote:

But by that argument, deprecated features would never ever get
removed, and so rendering the term "deprecated " redundant.

How do you figure? There has be a review of the benefits versus
detriments.

Obviously the review has already been done on depreciated elements
hence why they are depreciated. If there is no reason to remove them
at all, they wouldn't be depreciated!

Deprecated. The reason elements are deprecated rather than removed
outright is to let people know and to do the evaluations that determine
when, if ever, those elements will be removed.

If you deprecate something, and no one cares, then it can be removed
quickly. On the other hand, if it will have a huge affect, then it's
smart to wait and see.

Conversely, if all deprecated elements are removed
immediately, there's also no need for the term.

Agreed. Depreciated is the stage before the item is to be removed --
to give everyone time to stop using it (and to prevent new people from
using it). Once you've given everyone enough time to stop using it,
you remove it. I don't see the problem here.

How much time? THAT is the question. There are some deprecated elements
in C and C++ that expect will outlive me.

Brian