Anybody interested in my two cents? (I shouldn't have asked as I'm going
to tell you anyway.)
<rant mode on>
"You will break many more scripts by dropping [] for strings than the
other way around. Do you agree?" - Heck, this sounds as if you're doing
a "let's drop stuff for some technical reason no average PHP coder will
understand" contest and choosing which one to remove based on some rough
estimates.
You're simply deciding for the one you expect a lower collateral damage
from. You're ignoring that it's the one you proclaimed as the "new right
way" to do things.
Your credibility gets lost. Credibility is the foundation for broad
acceptance of projects like PHP.
New users will simply be upset and try the other language currently
hyped (guess what). If you tell professionals making the IT decisions in
larger companies about the stuff that recently happened or happens here,
guess what they will tell you? They don't dare to use PHP because nobody
guarantees them that the language itself is reasonably stable and
predictable; they want something to rely on, with upgrade paths that
will cause them no problems (and they're willing to spend money on
license costs or whatever as long as they don't have to touch or rewrite
their code every half a year).
Take a more professional attitude. You cannot say things like "well,
that was a mistake, nobody picked it up anyways, we just revert it".
This is a smack
in the face of developers acting in good faith and following your
recommendations. You can do stuff like that on unstable code or in CVS
head - but you cannot add {} and deprecate [] on PHP4, keep it on PHP5
and revert on PHP5.1.
Honestly, during the last few months I got the impression that people
making such decisions only see whether they need a feature or how much
it affects their own projects or their own company's codebase.
Maybe there are simple ways to scan codebases and find possibly affected
lines of code. Maybe the workaround is simple. Maybe it is as silly as
it was with "return new Foo();" => "return $tmp =& new Foo();". But, you
can make this once, but you cannot tell people to touch their code over
and over again with every new release.
--
And yet another thing: why is a change like this made in RC5 at all?
In the best case, people with large projects/codebases out there will
test their code before the release comes out. Early snapshot tests help
to find out about fundamental changes so you can tackle fundamental
problems early. But the new release may not be stable enough so this
cannot be the final test.
RC1 is a point in time where you would definetly start testing your
apps, as it won't be too long for the release to come out. OTOH, you
should expect the RCs to be sufficiently stable, to that if your code
passes tests with RC1, you can lean back. Everything else that follows
should just fix small glitches that have been overlooked before.
Even the attempt of trying to change or remove some language feature
like the {} thing IN A RC5 is unbelievably unprofessional.
You cannot happily attach "RC" to the version number when you feel that
you're "almost done". Oh, hm, lets make another modification, roll a new
RC. The "RC" suffix is worth nothing in this case.
When it's a RC, it's feature freeze. Test. Fix small bugs. No more
additions. No changes. If a major problem is detected, abort, go back to
workbench and correct it. Remove the "RC" from the version unless you're
done.
Anything else is like trying to quickly put in some newly designed
engine parts on the space shuttle - while it is at the launch pad at T-4
seconds. And keep the countdown running.
<rant mode off>
Sorry, but I just swallowed that bitter 4.4.0 pill. I tried to see the
migration to PHP5 as an opportunity to review old code. But the way this
possible change was introduced now is making me go nuts.
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
