150  6297 
.... 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.
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.
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
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
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.
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.
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
On 20 Dec 2005 13:52:17 -0800, "Chung Leong"
<ch***********@hotmail.com> wrote: 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.
I don't agree that an engineer's don't care for aesthetics! In fact,
the products with the best aesthetics are often considered good
engineering.
But I do see a conflict between "solving a problem" and doing it "the
PHP way". I loved the early years of PHP (after switching from ASP)
because each new revision would include some feature I desperately
wanted in the previous version. There were solving problems as fast
as I was coming up with them.
Lately, things have been leaning away from solving problems and more
towards to trying to do things "the PHP way" -- whatever that is. For
example, I want type-hints for all the variable types so I don't have
to double check the parameters to my functions are, for example,
actually integers! That would be USEFUL! But that feature is ignored
because it's not "PHP like".. what the hell. So we have to write
type-checking code over and over because they don't want to pollute
the language with a useful feature? That's far from the only example.
I think PHP5 was a good step in the right direction in principle. We
need the features that it provides. But then there's lots of
overengineering going on as well -- especially with respect to the
built-in classes; there's a dozen different iterator types but I've
never used a single one of them -- and I haven't seen any code that
does either. What problem is all this code trying to solve?
On 20 Dec 2005 23:53:00 GMT, "Default User" <de***********@yahoo.com>
wrote: 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.
Of course, given that PHP issues a warning (under E_STRICT) for
depreciated elements the effect is pretty huge always. Unlike
compiled languages like C/C++ were the warning exists only at compile
time, PHP warnings have a much bigger effect.
How much time? THAT is the question. There are some deprecated elements
in C and C++ that expect will outlive me.
PHP should move at a much faster pace than C/C++. There are
significant differences between the platforms, the applications, and
the environments that they aren't entirely comparable. Since PHP5
breaks so much backwards compatibility anyway I don't think
depreciated elements should stick around as long -- it's not as if you
have as much legacy code around that is running that is not already
being modified.
PHP also has way more mistakes in it than, for example C/C++, that
should be corrected. PHP started out as a big ball of hacks!!
Oli Filth wrote: 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.
"Secondary" hardly means "it should be ignored." To spell out the
obvious, secondary means "not primary" and objectives that are
secondary do not take precedent over those that are primary. The
primary objective of PHP is to run PHP code. If a new version of PHP
cannot run a piece of existing code, then it fails. In engineering, of
course, failures aren't always avoidable and might be acceptable
provided that they're small or happen rarely. To argue though, that if
we fail once we should fail some more, is simply crazy.
By most measures PHP 4 has been a great engineering success so I don't
know what you're hinting at.
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.
Well, implementing something because critics are laughing at you is not
exactly good engineering now is it? Embarassment is hardly a technical
parameter either. Vanity is a trait of many an academics, so I think
you're proving my point.
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...
Bad coding won't get you any closer to a working program so I don't see
the logic in this prophecy of your. What I do know is this: a working
program is better than a non-working one with polymorphism.
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.
Computer languages are called languages for a reason. Fundamentally,
that's how they're used: a programmer is communicating his desires to
the computer. A good language allows its user to efficiently express
the widest range of ideas. As no one can anticipate what others will be
thinking, a language developed unguided by usage will inevitably be
overly introspective that cramps people's thought. It's no accident
that PHP is as successful as it is. The ad hoc manner by which it
developed is the source of its strength, not its weakness.
That was the linguist in me speaking :-)
Wayne wrote: On 20 Dec 2005 23:53:00 GMT, "Default User" <de***********@yahoo.com>
wrote:
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.
Of course, given that PHP issues a warning (under E_STRICT) for
depreciated elements the effect is pretty huge always. Unlike
compiled languages like C/C++ were the warning exists only at compile
time, PHP warnings have a much bigger effect.
How much time? THAT is the question. There are some deprecated elements
in C and C++ that expect will outlive me.
PHP should move at a much faster pace than C/C++. There are
significant differences between the platforms, the applications, and
the environments that they aren't entirely comparable. Since PHP5
breaks so much backwards compatibility anyway I don't think
depreciated elements should stick around as long -- it's not as if you
have as much legacy code around that is running that is not already
being modified.
PHP also has way more mistakes in it than, for example C/C++, that
should be corrected. PHP started out as a big ball of hacks!!
Wayne,
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. Most deprecated functions can be recreated with other PHP
code. And if it can't, he can always go back to the previous version's
PHP source and compile that section of the code into the new PHP version
(or at least something which does the same). A definite advantage of
having the source!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Q: "Can you name me one single problem where introducing
case-sensitivity was the solution?"
A: Consistency.
Inconsistency is not a "real" problem as it does not cause the program
to produce wrong results. The fact that you personally like all
variables and function names to be in one case or the other is nothing
but a personal view and should NOT be forced upon others.
The idea of consistency might be good in theory, but the fact that this
allows the SAME word to have DIFFERENT meanings just because of a
slight change in case is far more serious. But that's just my opinion.
>> 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.
Type hinting is good, but this is an *addition* to the laguage that has
no effect on existing code.
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.
Automatic string-number conversion is there for a very good reason -
all input received from the HTML form is delivered as a string
regardless of whether it's supposed to be a date, a number or whatever.
The *feature* means that the programmer does not have to waste time
performing manual type conversions before being able to process each
field.
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!
If you give it a string or a number, yes. But insisting that a null
value cannot automatically be treated as an empty array is going over
the top.
>> ... 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.
Comparing a computer language with an operating system or device driver
is wandering off track. Expecting an ancient DOS program to run under
the latest version of Windows is unrealistic. I would, however, expect
a DOS program to run under *any* version of DOS just as I would expect
PHP code that I wrote last year to run under next year's version of
PHP.
>> ... 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.
You are missing the point. Writing code that satisfies the end users
takes a higher priority than writing code that satisfies the
programmers. Clean code that does not satisfy user requirements is
useless. Code that *does* satisfy user requirements, whether clean or
dirty, is a step in the right direction. Having code which is both
useful and clean would be perfect, but in this cruel world nothing is
ever perfect.
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.
Now there I would agree 100%. Every time I see the ternary operator I
want to puke.
>> 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*.
You are missing the point. I'm talking about the situation where a
developer looks at an existing function which works in thousands (if
not millions) of scripts, and decides that the code is not elegant or
clean enough for his taste, so he decides to refactor it, but this
refactoring then breaks a lot of scripts. The argument that the code is
now *cleaner* or *purer* is irrelevant to the customers - all they know
is that previously valid scripts do not work any more. They do not care
if the code is clean or dirty, just that it keeps on working as
expected.
>>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.
The origins of PHP syntax are irrelevant. What I am objecting to is
that people moving to PHP from other languages look at the current PHP
syntax and see that it is different from what they are used to, and
they want it to change so that they do not have to cope with the
differences. If they cannot learn to cope with the differences then
they should not bother trying to use a different language.
>> "Removing function aliases does nothing except annoy users." It increases the documentation and the confusion.
Having function aliases does not confuse me. I have seen it in several
languages, and it has never caused me or my fellow developers any
problems. As for documentation, "Function X is an alias of Function Y"
does not take up much room, does it?
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.
You are assuming that each of the 23 million sites that use PHP have
programming staff on hand to perform these "clean up" operations with
every new release of PHP. How wrong you are! A large number do not
have any programming staff at all, they just use open source scripts
and expect them to work. If they have to spend a fortune in buying new
scripts they might as well switch to a new and reliable language. I
hear Ruby on Rails is getting *very* good reviews.
>> "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.
But wouldn't you agree that it was initially a documentation fault for
not adequately identifying what was *correct* and *incorrect* usage?
And was it not a language fault for not trapping some of this
*incorrect* usage much earlier instead of letting it carry on and cause
memory corruptions?
>> "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?!?
Again you are missing the point. I am not talking about the language
doing something unintended, I am talking about where the programmer has
used a variable reference which used to work but which now fails. It
has been stated that it would be possible for the language to detect
this situation but, instead of rejecting it outright, could work around
it without producing a memory corruption and produce an E_NOTICE or
E_STRICT to warn the programmer of the dodgy code. If it is possible to
allow existing code to continue working but *without* causing a memory
corruption, then this surely has a greater priority than making an
unknown number of existing scripts to fail outright.
>> "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.
For your information I have worked on UNIVAC mainframes, mini-computers
from Data General and Hewlet Packard, and PCs running Windows. None of
these have been case-sensitive. I have programmed in assember, COBOL,
FORTRAN, SPL, QUIZ, QUICK, QTP, INSIGHT, TRANSACT and UNIFACE. None of
these languages has ever been case-sensitive. I have spent most of my
career working in software houses providing business applications for
business customers, so I would not consider myself to be out of the
loop.
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?
Chung Leong wrote:
<snip> The ad hoc manner by which it
developed is the source of its strength, not its weakness.
At that time PHP wasn't used in big projects, IMHO. When you start
using PHP in bigger projects (say, more than at least 5 person team),
you start facing problems because of ad hoc invention. Person A uses
different documentation style, Person B uses different function alias,
etc--that's the reason for the "standards" in companies. Well,
companies can bring a coding standards saying that don't use funcX, use
funcXAlias; but it's certainly an err at PHP end.
BTW, it's really funny to name a person works in ad hoc manner
(*just* getting things done) with "Engineer":-)
<OT>Aren't you Academician? IIRC, you're with University?</OT>
--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
On 21 Dec 2005 01:03:48 -0800, to**@marston-home.demon.co.uk 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.
The fact that you personally like all
variables and function names to be in one case or the other is nothing
but a personal view and should NOT be forced upon others.
I see no reason not to force it on others. 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.
I'm not sure why you've chosen to break your response into multiple
usenet postings. I'm going to coalese them in my response:
The origins of PHP syntax are irrelevant. What I am objecting to is
that people moving to PHP from other languages look at the current PHP
syntax and see that it is different from what they are used to, and
they want it to change so that they do not have to cope with the
differences. If they cannot learn to cope with the differences then
they should not bother trying to use a different language.
I'd like you to give me an example of this! I mean what changes do
people want? PHP already looks like C, C++, PERL, and Java? Do they
want to include some Haskel or Lisp syntax in there too?
As for documentation, "Function X is an alias of Function Y"
does not take up much room, does it?
Yes it does, in the index! Each duplicated function takes up twice as
much room in any list of available functions. Anyone learning PHP
will have to wade through even more documentation even if half of it
says "Function X is an alias of Function Y"
You are assuming that each of the 23 million sites that use PHP have
programming staff on hand to perform these "clean up" operations with
every new release of PHP.
I would assume that only major x.x releases would have such changes
and in the history of PHP those have been pretty rare. PHP4 has only
had 4 major releases in it's many-year lifespan.
Either the 23 million sites that use PHP have programming staff on
hand or they are using some commercial or open source software. If
they are using commercial or open source software I would assume that
those projects would be updated. Given that many products have kept
up to date with the many changes in PHP4 (including good 'ol
register_globals) it doesn't seem like a huge task.
If they have to spend a fortune in buying new
scripts they might as well switch to a new and reliable language.
If they spend a fortune buying scripts in the first place, I'd expect
those scripts not to use depreciated features. It's not like things
would be yanked out without plenty of notice.
But wouldn't you agree that it was initially a documentation fault for
not adequately identifying what was *correct* and *incorrect* usage?
In my case, it was *clearly* incorrect usage. The function should not
even have been defined to return a reference. It was just plain
wrong. In fact, I imagine you would only encounter this problem with
functions are returning references when it makes absolutely no sense
to do so. This isn't really a documentation issue.
And was it not a language fault for not trapping some of this
*incorrect* usage much earlier instead of letting it carry on and cause
memory corruptions?
Clearly it was a bug -- and a long standing one at that. They fixed
the bug. Fixing the bug caused some incorrect scripts to break. It
seems pretty cut and dried to me. I'm not sure I'm willing to
sacrifice performance of every single function call just to ensure
that incorrect script continue to work correctly -- because that's the
alternative.
Again you are missing the point. I am not talking about the language
doing something unintended, I am talking about where the programmer has
used a variable reference which used to work but which now fails.
You're missing the point. For the programmer to have a problem, he
would have to be using references in a situation that clearly doesn't
make sense to use references.
It
has been stated that it would be possible for the language to detect
this situation but, instead of rejecting it outright, could work around
it without producing a memory corruption and produce an E_NOTICE or
E_STRICT to warn the programmer of the dodgy code.
....And eat up considerable CPU cycles for each and every function
call. You can't just keep throwing more code at problems! Even the
smallest overhead in the function call mechanism can waste a
considerable amount of CPU cycles.
On 21 Dec 2005 02:16:11 -0800, to**@marston-home.demon.co.uk 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. For God's sake WHY! What problem existed in the
case-insensitive world that needed to be fixed?
Unicode.
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.
The only reason languages like Fortran are case-insensitive is because
punch cards and many early terminals only had uppercase characters.
On Wed, 21 Dec 2005, to**@marston-home.demon.co.uk wrote: 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.
Now there I would agree 100%. Every time I see the ternary operator I
want to puke.
Why? Once you know it exists, it makes coding certain things very much
more efficient, e.g.
echo "You have $total " . (count ($total) == 1 ? 'item' : 'items') . '.';
rather than the verbose
if (count ($total) == 1) {
$tempWord = 'item';
} else {
$tempWord = 'items';
}
echo "You have $total {$tempWord}.";
unset ($tempWord);
or
$foo = (isSet ($_GET['foo']) ? $_GET['foo'] : 'default');
It's not as if this construct only exists in PHP.
Martin to**@marston-home.demon.co.uk wrote: 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*.
You are missing the point. I'm talking about the situation where a
developer looks at an existing function which works in thousands (if
not millions) of scripts, and decides that the code is not elegant or
clean enough for his taste, so he decides to refactor it, but this
refactoring then breaks a lot of scripts. The argument that the code is
now *cleaner* or *purer* is irrelevant to the customers - all they know
is that previously valid scripts do not work any more. They do not care
if the code is clean or dirty, just that it keeps on working as
expected.
Not at all. If a refactoring breaks something, it is by definition not a
refactoring. But that is beside the point. I encountered far too much
code that was beyond maintenance.
"Don't touch that code. It works, OK?"
"What does it do then exactly?"
"We don't know, but it works!"
I heared this conversation at least 200 times. It is exactly my
definition of broken software. Working software (if I create or maintain
it) is something I have control of. I know the state of my code, because
the unit tests tell me what state it is in. When I change a line of
code, even if I have a less then bright day, I still know the
consequences just by running the tests. Working software is not some
cute image on my screen, but proof that the components do what they are
supposed to. And that they obey their contract. If the code has become a
minefield it is definitely broke. Worse even. You can't repair what you
can't touch.
It is absolutely not irrelevant to the customers wether the code can be
maintained or not. Or how dangerous that is, or how much time it would cost.
Especially when environments change. The OS changes, the language
changes, the computer hardware changes, the goal or use of the
application changes and all those changes can call for maintenance. I
think no company or programmer can afford to say to a customer that a
piece of code is declared "not broke" and, oh, beyond fixing. A dirty
hack is a time bomb. It is only safe to use one if you are 100% sure you
disarm it in time. If not, it is guaranteed to blow in your face when
you least expect it.
Best regards
Chung Leong wrote: Oli Filth wrote:
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.
"Secondary" hardly means "it should be ignored." To spell out the
obvious, secondary means "not primary" and objectives that are
secondary do not take precedent over those that are primary.
Hmm, "ignored" was a bit strong. I think "put to one side" or "added as
an after-thought" was what I meant. ;)
By most measures PHP 4 has been a great engineering success so I don't
know what you're hinting at.
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 incompatibilities, nonsense like magic quotes, ...
That's what I was hinting at.
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.
Well, implementing something because critics are laughing at you is not
exactly good engineering now is it? Embarassment is hardly a technical
parameter either. Vanity is a trait of many an academics, so I think
you're proving my point.
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).
The support and interest of professional software developers is crucial
for the continued advancement of PHP, IMO.
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...
Bad coding won't get you any closer to a working program so I don't see
the logic in this prophecy of your.
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...?", to which the answer is "use arrays instead", to which
their response is "well, my variables do the job, so why should I?". If
people don't take the time to learn good practice, they'll never see
*why* the things they were doing before were bad practice - that's what
I meant by self-fulfilling prophecy. If the language can help enforce
some aspects of good practice, then that's a good thing IMO.
Computer languages are called languages for a reason. Fundamentally,
that's how they're used: a programmer is communicating his desires to
the computer. A good language allows its user to efficiently express
the widest range of ideas. As no one can anticipate what others will be
thinking, a language developed unguided by usage will inevitably be
overly introspective that cramps people's thought. It's no accident
that PHP is as successful as it is. The ad hoc manner by which it
developed is the source of its strength, not its weakness.
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 "ad hoc" manner in which PHP has been developed is indisuptably the
source of many of its weaknesses. It might also be the source of its
strengths, but possibly because many of those strengths are aspects
which should have been thought of in the first place.
--
Oli
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 to**@marston-home.demon.co.uk 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
Wayne wrote: On 21 Dec 2005 01:03:48 -0800, to**@marston-home.demon.co.uk 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.
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($thing) == 'myname') ...
Now I've no objection to being *able* to do that, but being forced to
(because get_class($thing) will *never* equal 'MyName', which is what I
called the class) is wrong. So in this instance anyway, I prefer PHP5's
approach.
Colin
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 incompatibilities, 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?
t...@marston-home.demon.co.uk 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?
On 21 Dec 2005 01:03:48 -0800, t...@marston-home.demon.co.uk 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.
> 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".
>> 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.
On 22 Dec 2005 01:35:31 -0800, to**@marston-home.demon.co.uk wrote: On 21 Dec 2005 01:03:48 -0800, t...@marston-home.demon.co.uk 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.
On 22 Dec 2005 01:40:17 -0800, to**@marston-home.demon.co.uk 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.
On 22 Dec 2005 01:51:24 -0800, to**@marston-home.demon.co.uk wrote: 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.
Umm, no I'm not. All languages are written in English and ASCII.
Java, for example, is written in Unicode (UTF-8).
That is what I have been used to for decades, and I see absolutely no
advantage in being forced to switch.
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??
On 22 Dec 2005 01:21:40 -0800, to**@marston-home.demon.co.uk wrote: 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?
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.
Chung Leong wrote: 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 incompatibilities, 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.
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.
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 wish it were true...!
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'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.
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.
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. 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.
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. 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.
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
Wayne wrote: 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.
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.
>> 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!
Any programmer who deliberately mixes case like that is a candidate for
the unemployment queue.
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,
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.
to a case-insensitive compiler they are
the same.
And to a person who has been using case-insensitive compilers for 30
years 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.
In my current (non-PHP) contract the convention is that everything
which is part of the language (variable and function names) is
lowercase while evreything created by a programmer is in UPPER case.
Different organisations have different conventions, but if the compiler
is case-insensitive I really don't see the point. The argument that the
use of case *must* be consistent doesn't hold water. It's so low on the
scale of things which are *imporatnt* that it doesn't even register.
>> 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 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.
I disagree. The majority of programmers that I have worked with on
case-insensitive languages do NOT like being told that case is suddenly
important, that you must use one in preference to the other. It is like
saying that although the language allows you to do something either
*this* way or *that* way from now on everybody MUST do it *that* way
for no other reason than to be consistent.
>> 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
Who gives a toss about how java does it? This is a PHP topic.
>> 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.
So you are forcing your personal preferences upon everyone else. That
sucks.
>> That is what I have been used to for decades, and I see absolutely no advantage in being forced to switch.
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??
So why should I have to change MY programming habits just to match YOUR
programming habits? Who put you in charge? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jason Mobarak |
last post by:
Greetings!
Say that it's desirable to provide backwards compatibility for methods
of an object, consider the case where...
class Foo:
def bar (self, a, b):
pass
....is a defined class...
|
by: Sonny |
last post by:
I need to port a library that is written entirely in C to C++. The
library is supported on quite a few platforms (windows, Solaris,
Linux, AIX, HP-UX, OSX, etc...) and there's quite an existing...
|
by: py |
last post by:
I have function which takes an argument. My code needs that argument
to be an iterable (something i can loop over)...so I dont care if its a
list, tuple, etc. So I need a way to make sure that...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
