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

[Default User]

Jerry Stuckle wrote:

I agree with you. Deprecated elements should be removed eventually.
Not necessarily the next release, but they shouldn't be kept around
forever, either.

And if Default User needs the function that badly, he can always
recreate it.

This merely demonstrates that you didn't follow what I said. Likely
that's my fault. My point was that the removal of deprecated elements
in any programming language has to be weighed against the overall
effect of both retention and removal.


Brian

[Default User]

to**@marston-home.demon.co.u k wrote:

My point is that for 30 years I have worked with tools which were
totally insensitive to case, but some morons seem to think that case
is important.
I guess C, C++, and UNIX are not particularly popular.
For God's sake WHY! What problem existed in the
case-insensitive world that needed to be fixed?

Ask Dennis Ritchie.
Brian

[Colin Fine]

Wayne wrote:

On 21 Dec 2005 01:03:48 -0800, to**@marston-home.demon.co.u k wrote:

Inconsisten cy is not a "real" problem as it does not cause the program
to produce wrong results.

Correct. But I would argue that programs are meant to be read by
humans at least as much as by the computer. Humans see a variable
called $foo and $foO to be different.

Er ... no. Only if they have been exposed to case-sensitive languages or
systems.

In my view, case sensitivity was one of the biggest mistakes the Unixers
made in the first place.

However, it is now pretty common, though not universal.

Oddly, having argued this, I'm going to say something in favour of PHP5.
I'm not aware of all the ramifications (I haven't done a great deal of
PHP5 yet), but it always stuck in my craw having to say (in PHP 4):

class MyName ....

if (get_class($thi ng) == 'myname') ...
Now I've no objection to being *able* to do that, but being forced to
(because get_class($thin g) will *never* equal 'MyName', which is what I
called the class) is wrong. So in this instance anyway, I prefer PHP5's
approach.

Colin

[Chung Leong]

Oli Filth wrote:

I agree, it's a widespread success, but its also a big sprawling heap of
hacks, afterthoughts, inconsistent function names and parameter lists,
function aliases, issues with references that no-one really knows how to
deal with, version incompatibiliti es, nonsense like magic quotes, ...
That's what I was hinting at.
Aesthetics. Aesthetics. Perhaps one of these days you will come to grip
with the nature of this world. The ugly win because they do what it
takes to win, while the beautiful disappear into oblivion. Just look at
how Windows has prosper while the BeOS is in the technology wastebin.

Incidently, I say the same thing to my historian friend, who, despite
all empirical evidence to the contrary, thinks that the principled
politician would always carry the day.
I wasn't referring to "critics" in the sense of academics, but to
real-world programmers who might have wanted to use PHP if it weren't
such a mess (compared to other languages).
Let them use whatever language they were using then. What's this crazy
obsession with needing to "convert" people?! PHP is not a religion--it
is a tool. It is useful to me and thousands of other developers. If you
don't want to use it, well, it's your loss. From an engineer's point of
view you wouldn't alter a product to suit the desires of people who
aren't even using it--because it's goddamn stupid. Only idle academics
live for this kind of vainglory.
Bad coding *can* get you closer to a working (in one sense of the word)
program - I've seen countless posts in PHP newsgroups where newbies have
asked things like "How can I loop through my variables $thing1,
$thing2...?"
That's just igorance. We all know that using an array in this
particular situation is easier. And once someone learn an easy way to
do something, he/she wouldn't go back.
to which the answer is "use arrays instead", to which
their response is "well, my variables do the job, so why should I?".
Very good question to ask in fact. If all you can offer is a
non-technical value-judgement: "it's good practice," then you're a sort
of priest of programming, not a software engineer.
How about C or C++? They're immensely successful, far more widely used
than PHP, and comparatively they're set in stone - you don't get Bjarne
Stroustrup (chief mind behind C++) going "oh, I think we'll change the
semantics of pointers and references" every 5 minutes. Yes, these
languages get new features added from time to time, but because they
were planned so well in the first place, they very rarely lead to
backwards incompatibility .

The changes in PHP 5 were driven from above, without regards to the
needs of the user community. That gets us back to the original topic of
backward compatibility. Do you really think longtime PHP programmers
want their existing code to break? You yourself said that these changes
are made to please people are not programming in PHP. Now what benefits
do I get if Bob Bobinski the Java guru is converted to PHP? Does it
make my job easier? My programs run faster? Are my sites more secured?

[tony]

[e-mail].u k wrote:

My point is that for 30 years I have worked with tools which were
totally insensitive to case, but some morons seem to think that case
is important.

I guess C, C++, and UNIX are not particularly popular.
They may be popular in some circles, but I have never travelled in
those circles.
For God's sake WHY! What problem existed in the
case-insensitive world that needed to be fixed?

Ask Dennis Ritchie.

No, I'm asking you. What problem existed in the case-insensitive world
that could ONLY be solved by introducing case-sensitivity?

[tony]

On 21 Dec 2005 01:03:48 -0800, [e-mail].u k wrote:

Inconsistency is not a "real" problem as it does not cause the program
to produce wrong results.

Correct. But I would argue that programs are meant to be read by
humans at least as much as by the computer. Humans see a variable
called $foo and $foO to be different.

I disagree. I have worked for decades with case-insensitive languages
and I have always treated $FOO and $foo as the same variable. It does
not matter to me whether it is written all upper case or all lower
case, it is exactly the same thing. I have worked with different teams
who had had entirely different standards - some like all upper case,
some like all lower case, all for different reasons. What I object to
is being told that I MUST use one case or the other just to be
*consistent* with everyone else, especially when I disagree with their
reason for choosing one case over the other in the first place. The
language has no difficulty in recognising a word regardless of its
case, and neither do I.

By introducing case-sensitivity you are suddenly saying that $FOO and
$foo are now different, which goes against the grain of everything that
I have been taught since my first day at school way back in the last
century.

The person who dreamed up case-sensitivity is a sadist and a moron who
should be publicly flogged. But that's just my opinion.

[tony]

> There is no legitimate reason to have variables named $foo, $foO,

$FOO all refering to the same thing.

I will however concede that there is also no reason that $foo, $foO,
and $FOO should point to different things either! Which is your main
objection and I agree.

Your second statement contradicts the first, but at last you agree that
having $FOO and $foo point to different things is not a good thing. If
this is as a result of introducing case-sensitivity, then
case-sensitivity must itself be "not a good thing".

[tony]

>> My point is that for 30 years I have worked with tools which were

totally insensitive to case, but some morons seem to think that case is
important. For God's sake WHY! What problem existed in the
case-insensitive world that needed to be fixed?

Unicode.
Explain. I write scripts with an editor that stores in unicaode without
any problem, so what exactly is the problem?
In order to determine if two strings match entirely based on case you
have to take a lot of things into consideration. It's no longer
sufficient to say A-Z maps to a-z.
You are talking about the *contents* of variables, whereas I am talking
about the *names* of variables. There is a BIG difference between the
two.
The only reason languages like Fortran are case-insensitive is because
punch cards and many early terminals only had uppercase characters.

True, but when punched cards where replaced by terminals and keyboards
which had the capability of both upper and lower case it made no
difference which case was used as they were treated exactly the same.
Thus programmers could take their original code which was all upper
case and change it if they wanted to. Changing case was a matter of
human readability or personal taste, but the computer did not care -
the name of a function or a variable was exactly the same regardless of
which case was used.

That is what I have been used to for decades, and I see absolutely no
advantage in being forced to switch.

[Wayne]

On 22 Dec 2005 01:35:31 -0800, to**@marston-home.demon.co.u k wrote:

On 21 Dec 2005 01:03:48 -0800, [e-mail].u k wrote:

Inconsistency is not a "real" problem as it does not cause the program
to produce wrong results.

Correct. But I would argue that programs are meant to be read by
humans at least as much as by the computer. Humans see a variable
called $foo and $foO to be different.

I disagree. I have worked for decades with case-insensitive languages
and I have always treated $FOO and $foo as the same variable.

But I didn't say $FOO or $Foo. I said $foo and $foO! People have no
trouble will all caps or the first letter capitalized. What about the
difference between setsLower() and setSlower()? To a human reader
those have different meanings, to a case-insensitive compiler they are
the same.
some like all upper case,
My god. I wouldn't want my code constantly shouting at me. All upper
case is harder to read, too.
What I object tois being told that I MUST use one case or the other just to be
*consistent* with everyone else, especially when I disagree with their
reason for choosing one case over the other in the first place.
The majority of programmers disagree with you on this. Consistency
and conventions are preferred when working on a particular project or
platform -- it cuts down on errors and allows one to convey greater
meaning.
By introducing case-sensitivity you are suddenly saying that $FOO and
$foo are now different, which goes against the grain of everything that
I have been taught since my first day at school way back in the last
century.

A common Java idiom is:

Foo foo = new Foo();

The convention in Java is that class names begin with an upper-case
letter and variables begin with a lowercase variable. I can clearly
see what is happening here.

To get the same meaning if it was case-insensitive, you'd have to do
something like:

FooClass fooInstance = new FooClass()

Which makes readability worse, not better.

[Wayne]

On 22 Dec 2005 01:40:17 -0800, to**@marston-home.demon.co.u k wrote:

There is no legitimate reason to have variables named $foo, $foO,
$FOO all refering to the same thing.

I will however concede that there is also no reason that $foo, $foO,
and $FOO should point to different things either! Which is your main
objection and I agree.

Your second statement contradicts the first, but at last you agree that
having $FOO and $foo point to different things is not a good thing.

It's not exactly a contradiction.. . I wouldn't allow both $foo and
$FOO in the same program. In a case-insentive language that's
allowed. I would want that completely disallowed.

That's a bit difficult in a free-form language like PHP but in
languages with variable declarations, the variable would have to match
the declared case otherwise it would be an error.