|
|
Posted by Wayne on 12/20/05 22:46
On 20 Dec 2005 06:45:14 -0800, tony@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/bc-is-everything.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.
Navigation:
[Reply to this message]
|