Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20206
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 20 Nov 2005 21:16:25 +0100
Content-class: urn:content-classes:message
Message-ID: <00A2E2156BEE8446A81C8881AE117F192C1BD1@companyweb>
Thread-Topic: AW: [PHP-DEV] Curlies again [was: Upgrade notes for PHP 5.1 - final draft]
Thread-Index: AcXuBYvWl8+fdvq/STK4SactLJrDkwAAiTLQ
To: "internals" <internals@lists.php.net>
Subject: AW: AW: [PHP-DEV] Curlies again [was: Upgrade notes for PHP 5.1 - final draft]
From: mp@webfactory.de ("Matthias Pigulla")

> This is a non-issue for phpDocumentor.  All we need is at=20
> least 6 months=20
> to a year of lead time on the final decision in order to=20
> adjust the code.

As I wrote, I happend to have Smarty and phpDocumentor checkouts at
hand. I just checked a recently installed version of Mediawiki and they
also use curlies (although only in a very few places). But at least this
should be a good argument against "nobody out there is using them
anyway". Let alone all the other good reasons. Oh, btw, phpMyAdmin also
uses them.=20

> However, it is obvious that a script is needed that iterates over a=20
> script and changes things that are easy to fix like the=20
> $a{blah} one.  I=20

Yeah, someone just started a thread regarding this idea. As to this
special case, maybe you can automagically find exactly the affected or
possibly affected lines of code and update them.

But more generally, I think writing the "general purpose automagical
updater" is infeasible because sooner or later you'll run into issues
you cannot detect or fix with a lint-type analysis but that require real
execution of all possible code paths (e.g. stricter function argument
parsing, changes in handling of NULL when used in array functions,
passing non-array to array_merge...). Even worse, something like
reordering function arguments (as somebody mentioned shortly mentioned
here?) can only be detected by having specifically written test cases at
hand.

> 2) be thankful this is transparent enough that we can have=20
> enough lead=20
> time to make small changes to legacy scripts as needed - this=20
> is why the=20
> E_STRICT is added to PHP 5.1 now.  Would you prefer a sudden break in=20
> PHP 6 without any warning?

Apart from that nobody has given a sound reason yet (maybe I missed it)
why it needs a change at all, as we know from recent history there are
people out there who happen to get notices on their sites and consider
that "breaking things".=20

So for these people, this issue by itself is why things might "break" as
soon as their hosters upgrade to 5.1.

> 3) ALWAYS test RCs of releases when they come out with our critical=20
> applications and note any breaks here, to determine whether they are=20
> bugs or intentional changes in PHP.

That was yet another thing I felt disturbing and complained about but
noone has commented on that yet - why do you need to make changes like
this one in RC5? Every change that is later than an RC1 is more likely
to be missed by people, even those who are diligently testing their
stuff. Additionally, RC5 is damn pretty close to a release and that puts
unnecessary pressure on people to get it fixed.

Sorry for being so annoying.

-mp.