Breaking backwards compatibility - good or bad?

[Default User]

Re: Breaking backwards compatibility - good or bad?

Jerry Stuckle wrote:

[color=blue]
> 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.[/color]


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]

Re: Breaking backwards compatibility - good or bad?

tony@marston-home.demon.co.u k wrote:

[color=blue]
> 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.[/color]

I guess C, C++, and UNIX are not particularly popular.
[color=blue]
> For God's sake WHY! What problem existed in the
> case-insensitive world that needed to be fixed?[/color]

Ask Dennis Ritchie.


Brian

[Colin Fine]

Re: Breaking backwards compatibility - good or bad?

Wayne wrote:[color=blue]
> On 21 Dec 2005 01:03:48 -0800, tony@marston-home.demon.co.u k wrote:
>
>[color=green]
>>Inconsisten cy is not a "real" problem as it does not cause the program
>>to produce wrong results.[/color]
>
>
> 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.
>[/color]
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]

Re: Breaking backwards compatibility - good or bad?

Oli Filth wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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...?"[/color]

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.
[color=blue]
> to which the answer is "use arrays instead", to which
> their response is "well, my variables do the job, so why should I?".[/color]

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.
[color=blue]
> 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 .[/color]

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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

t...@marston-home.demon.co.u k wrote:[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> I guess C, C++, and UNIX are not particularly popular.[/color]

They may be popular in some circles, but I have never travelled in
those circles.
[color=blue][color=green]
>> For God's sake WHY! What problem existed in the
>> case-insensitive world that needed to be fixed?[/color][/color]
[color=blue]
> Ask Dennis Ritchie.[/color]

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

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

On 21 Dec 2005 01:03:48 -0800, t...@marston-home.demon.co.u k wrote:
[color=blue][color=green]
>> Inconsistency is not a "real" problem as it does not cause the program
>> to produce wrong results.[/color][/color]
[color=blue]
> 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.[/color]

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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

> There is no legitimate reason to have variables named $foo, $foO,[color=blue]
> $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.[/color]

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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> My point is that for 30 years I have worked with tools which were[color=blue][color=green]
>> 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?[/color][/color]
[color=blue]
> Unicode.[/color]

Explain. I write scripts with an editor that stores in unicaode without
any problem, so what exactly is the problem?
[color=blue]
> 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.[/color]

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.
[color=blue]
> The only reason languages like Fortran are case-insensitive is because
> punch cards and many early terminals only had uppercase characters.[/color]

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]

Re: Breaking backwards compatibility - good or bad?

On 22 Dec 2005 01:35:31 -0800, tony@marston-home.demon.co.u k wrote:
[color=blue]
>On 21 Dec 2005 01:03:48 -0800, t...@marston-home.demon.co.u k wrote:
>[color=green][color=darkred]
>>> Inconsistency is not a "real" problem as it does not cause the program
>>> to produce wrong results.[/color][/color]
>[color=green]
>> 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.[/color]
>
>I disagree. I have worked for decades with case-insensitive languages
>and I have always treated $FOO and $foo as the same variable.[/color]

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.
[color=blue]
>some like all upper case,[/color]

My god. I wouldn't want my code constantly shouting at me. All upper
case is harder to read, too.
[color=blue]
>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.[/color]

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.
[color=blue]
>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.[/color]

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]

Re: Breaking backwards compatibility - good or bad?

On 22 Dec 2005 01:40:17 -0800, tony@marston-home.demon.co.u k wrote:
[color=blue][color=green]
>> 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.[/color]
>
>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.[/color]

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.

[Wayne]

Re: Breaking backwards compatibility - good or bad?

On 22 Dec 2005 01:51:24 -0800, tony@marston-home.demon.co.u k wrote:
[color=blue][color=green]
>> 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.[/color]
>
>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.[/color]

Umm, no I'm not. All languages are written in English and ASCII.
Java, for example, is written in Unicode (UTF-8).
[color=blue]
>That is what I have been used to for decades, and I see absolutely no
>advantage in being forced to switch.[/color]

So you're main argument is that it's not what you're used to -- so it
should be changed. Isn't that the attitude that your entire article
was arguing against??

[Wayne]

Re: Breaking backwards compatibility - good or bad?

On 22 Dec 2005 01:21:40 -0800, tony@marston-home.demon.co.u k wrote:
[color=blue][color=green]
>> Ask Dennis Ritchie.[/color]
>
>No, I'm asking you. What problem existed in the case-insensitive world
>that could ONLY be solved by introducing case-sensitivity?[/color]

Many many years ago it was done for compiler performance reasons. It
does require lots of extra cycles to lower-case every single
identifier in a large C application.

Might seem like a poor reason now, but as a COBOL/Mainframe programmer
should appreciate it -- It was only 2 extra bytes to store the entire
year but somebody decided that was too much.

[Oli Filth]

Re: Breaking backwards compatibility - good or bad?

Chung Leong wrote:[color=blue]
> Oli Filth wrote:
>[color=green]
>>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.[/color]
>
> 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.[/color]

In the 21st Century, where programming is as much about team-based
development and code maintenance planning as it is about knocking out
lines of code, aesthetics *are* massively important, IMO. Code that's
more consistent and easier to read is easier to understand, and easier
to hand over to another team member.


Note that despite the stance I appear to be taking, I definitely don't
agree with all the changes between 4 and 5, nor the proposed changes in
6. I see no advantage in changing constructor names to __construct,
changing the name of $this, continually changing string indexing syntax
back and forth, nor adding polymorphism of statics, for instance.

[color=blue]
> 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.[/color]

I wish it were true...!

[color=blue][color=green]
>>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).[/color]
>
> 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.[/color]

It's not a matter of trying to "convert" people, no-one's going to go
"oh, I've seen the light, PHP is better than C++, what have I been doing
all these years". But a large user-base (and incoming users with skills
and techniques from a different language) will benefit the PHP community
and existing users. A more focused language with better OO support and
less inconsistency will benefit existing users doing new development.

[color=blue]
> 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.[/color]

Umm, if you were trying to sell a product and there was an untapped
market, of course you would try to make future versions of your product
more attractive to them. Now obviously, PHP isn't being made for money,
but the developers probably have much the same goals as if they were
indeed selling it.

In the same way that hosts have to make a decision - do we want to keep
our existing customers happy by sticking with PHP 4 and push away
potential customers to other hosts that run ASP .NET or Java, or do we
want to attract new customers by running PHP 5 (or 6, when the time
comes), at the expense of making our customers make some trivial
revisions to their code? (When I say trivial, I mean that the actual
replacements themselves are trivial, the scale of the job may not be...)

Personally, I can't see why hosts can't run both 4 and 5, and keep
everyone happy.

[color=blue][color=green]
>>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...? "[/color]
>
> 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.[/color]

It's not necessarily about ignorance about individual issues. Being a
good programmer/software designer is about being able to take a top-down
view and work out, a priori, why certain approaches are better/more
applicable than others, rather than having to be told on a case by case
basis.

[color=blue][color=green]
>>to which the answer is "use arrays instead", to which
>>their response is "well, my variables do the job, so why should I?".[/color]
>
> 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.[/color]

You're right, it is a good question.

We all know that there are sound reasons behind most "good practice"
paradigms. The problem is that they're often quite hard to explain
concisely to relative newbies whose first and only exposure to
programming is PHP, and this is their only frame of reference. A frame
of reference where so many things are allowable, many of which will kick
them up the arse at a later date when their projects get larger and more
complex, and they realise that there's more to creating software than
just getting any old thing to work.

If someone's new to OO, for instance, but have found that there's this
neat thing called classes, if they discover classes through PHP then
more often than not they seem to end up trying to do things like using
classes as glorified arrays ("how can I loop through my class
members?"), or some bizarre reverse-polymorphism ("how can I find the
name of the function that called/created my object, so that I can get it
to different things accordingly?"). Completely missing the point, and
therefore the benefits, of OO. Trying to explain to them why abstract
base classes are beneficial, or why a class with only static members
isn't the same as a singleton, or why polymorphism is better than
dynamically defining classes, is extremely difficult.


--
Oli

[Chung Leong]

Re: Breaking backwards compatibility - good or bad?

Wayne wrote:[color=blue]
> 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.[/color]

In Delphi, the convention is to begin class name with the letter T.

foo :TFoo
[...]
foo := TFoo.Create();

The readability here is superior here than what you have in Java,
especially for letters where capitalization involves only a size
change: "Window window," "Vector vector," "Stream stream," etc.

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> I disagree. I have worked for decades with case-insensitive languages[color=blue][color=green]
>> and I have always treated $FOO and $foo as the same variable.[/color][/color]
[color=blue]
> But I didn't say $FOO or $Foo. I said $foo and $foO![/color]

Any programmer who deliberately mixes case like that is a candidate for
the unemployment queue.
[color=blue]
> 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,[/color]

Not to me, they don't. When writing a program I am writing in a
language that a computer understands, so I have to *think* like a
computer. To a computer the case of a word is irrelevant, and so is
it's pronunciation.
[color=blue]
> to a case-insensitive compiler they are
> the same.[/color]

And to a person who has been using case-insensitive compilers for 30
years they are the same.