On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote: > At 06:28 AM 3/14/2006, Pierre wrote: > >On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote: > > > Pierre and all, > > > > > > A while ago I suggested to add an UPGRADING file for the PHP 6 > > > upgrade, where we'd document every time we break BC and how to solve > > > that. For example, with nuking register_globals we could write what > > > we broke, and if really needed, what 1-2 liners they can write to get > > > the same behavior back (e.g. extract()). > > > >Are you asking me to write the docs about how to emulate register_globals? > >:-D > > Yes, definitely. We should write that we removed it because it's > insecure. However, we should provide people with the two liner which > is PHP based with a huge warning, in case they need it to work during > transition time. And some users are Intranet users who don't really > care about security in their app.
Intranet apps does not need to be secure? That's new to me. > I definitely think that this kind of documentation re: the upgrade > path is important and I thought we all agreed on doing this in the past... We agree on that, yes. I was even in the first to ask for migration docs. However a migration doc is not supposed to document how to keep doing things badly. So yes, I can write a doc about why register_globals is removed and how to fetch the various super variables (_get, _post, _request,...). But this is already well explained in the manual (remember that register_globals is off by default since years now). Maybe it is better to add that to a "Migrate to php 6.0" document? But again, I'm not the write person to write good docs. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
