|
|
Posted by Wayne on 12/21/05 12:41
On 21 Dec 2005 01:03:48 -0800, tony@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.
Navigation:
[Reply to this message]
|