Michael Shadle wrote:
On Fri, May 15, 2009 at 1:25 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschn...@cschneid.com wrote:
There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something *everybody* uses.
Apart from the fact that _REQUEST
Michael Shadle wrote:
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschn...@cschneid.com wrote:
There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something *everybody* uses.
Apart from
Jani Taskinen wrote:
Michael Shadle wrote:
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschn...@cschneid.com wrote:
There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something
2009/5/15 Michael Shadle mike...@gmail.com
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com wrote:
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.
although it would generate a
I think this strikes a good balance between backward compatibility...
I would hope though the code for it is very simple, to not add
overhead to PHP. Basically in PHP the pseudocode equivalent would be
if(ini_get('reigster_request') == true) {
$_REQUEST = array_merge($_GET, $_POST, $_COOKIE,
Michael Shadle wrote:
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com wrote:
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.
although it would generate a tonne of freelance work
On 15.05.2009, at 10:22, Rasmus Lerdorf wrote:
Michael Shadle wrote:
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com
wrote:
bc? all the reasoning in the world won't justify it to 1 million
businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.
Lukas Kahwe Smith wrote:
On 15.05.2009, at 10:22, Rasmus Lerdorf wrote:
Michael Shadle wrote:
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com
wrote:
bc? all the reasoning in the world won't justify it to 1 million
businesses
running php 4 code which is reliant on
On Fri, May 15, 2009 at 10:32, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 15.05.2009, at 10:22, Rasmus Lerdorf wrote:
Michael Shadle wrote:
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com wrote:
bc? all the reasoning in the world won't justify it to 1 million
On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few ugly legacy
features.
On 15.05.2009, at 19:14, Michael Shadle wrote:
On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith
m...@pooteeweet.org wrote:
The more stuff like this we remove, the harder it becomes for
people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more
On Fri, May 15, 2009 at 1:25 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to be legacy enough ?
There's
Am Freitag, 15. Mai 2009 schrieb Michael Shadle:
Hallo,
There's gotta be a time in the natural evolution to cut the cord so
to speak - Python just launched 3.0 and dropped backwards
compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I
care. But it really should align with a
Michael Shadle wrote:
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com wrote:
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.
although it would generate a tonne of freelance work :p
that code has to
16 matches
Mail list logo
