Richard Lynch wrote:
> I have taken the liberty of making an RFC for this:
> http://wiki.php.net/rfc/url_dots
>
> Feel free to add/edit it as fit, particularly since it's my first use
> of that RFC wiki, and I'm not good at wiki markup, and I probably
> missed something from this thread.
>
> I in
On 31.01.2010, at 9:11, Richard Lynch wrote:
> I have taken the liberty of making an RFC for this:
> http://wiki.php.net/rfc/url_dots
thanks. looks good to me
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I have taken the liberty of making an RFC for this:
http://wiki.php.net/rfc/url_dots
Feel free to add/edit it as fit, particularly since it's my first use
of that RFC wiki, and I'm not good at wiki markup, and I probably
missed something from this thread.
I intentionally left out the ?a_b=1&a.b=2
And I'm not sure who would actually use 'a.b' and then expect 'a_b',
but I have to assume somebody has done that, perhaps consuming an API
from somewhere else.
OpedID protocol uses dots in query string arguments. The
implementations could be broken by the patch.
While the "keep arguments as is"
> And I'm not sure who would actually use 'a.b' and then expect 'a_b',
> but I have to assume somebody has done that, perhaps consuming an API
> from somewhere else.
OpedID protocol uses dots in query string arguments. The
implementations could be broken by the patch.
While the "keep arguments as
>>
>> For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
>> another php.ini flag (sorry!) to choose the behaviour.
>
>-1 from me.
>I don't think we need to keep backward compatibility for this. PHP-6 is a
>major release, after all.
>
>It would be absolutely enough to add optional var-
Nathan Rixham wrote:
> Alexey Zakhlestin wrote:
>> On 21.01.2010, at 18:21, Richard Lynch wrote:
>>> For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
>>> another php.ini flag (sorry!) to choose the behaviour.
>> -1 from me.
>> I don't think we need to keep backward compatibility fo
Alexey Zakhlestin wrote:
> On 21.01.2010, at 18:21, Richard Lynch wrote:
>> For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
>> another php.ini flag (sorry!) to choose the behaviour.
>
> -1 from me.
> I don't think we need to keep backward compatibility for this. PHP-6 is a
> major
On Thu, Jan 21, 2010 at 10:38 AM, Alexey Zakhlestin wrote:
>
> -1 from me.
> I don't think we need to keep backward compatibility for this. PHP-6 is a
> major release, after all.
>
> It would be absolutely enough to add optional var-name conversion to extract()
Agreed.
--
-Jack Timmons
http://
On 21.01.2010, at 18:21, Richard Lynch wrote:
>
> For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
> another php.ini flag (sorry!) to choose the behaviour.
-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a major
release, after all.
It would be
Richard Lynch wrote:
> For BC, I suppose PHP could have *both* 'a.b' and 'a_b'
+1 as a PHP user. For BC, I guess this should go without changing the
current precedence rules too, annoying though it might be.
At the moment: "?a_b=foo&a.b=bar" gives $_GET === array('a_b' => 'bar')
As I understand it
Once upon a time, a long time ago, PHP imported all GET/POST/COOKIE
data as variables, for the convenience of the developer.
This was called "register_globals"
$a.b is not a valid variable name, so it was changed to $a_b to be a
valid variable name.
Nowadays, I see no real reason to keep doing t
Tim Starling wrote:
> Stan Vassilev wrote:
>> I hope PHP6 will remove this processing as register_globals will be
>> completely removed at that point.
>
> I'd be happy if it stayed like it is, for backwards compatibility.
Sometimes forwards compatibility has to take precedence though.
Linked da
I'd be happy if it stayed like it is, for backwards compatibility. If
not, then there needs to be some reasonably straightforward way for an
app to work out how PHP has messed up its input so that it can put it
back together (compare get_magic_quotes_gpc()).
In any case, it could be better docume
Stan Vassilev wrote:
>
> I hope PHP6 will remove this processing as register_globals will be
> completely removed at that point.
I'd be happy if it stayed like it is, for backwards compatibility. If
not, then there needs to be some reasonably straightforward way for an
app to work out how PHP has
On Wed, Jan 20, 2010 at 02:29:27PM -0800, Rasmus Lerdorf wrote:
> Well, that conversion still needs to happen somewhere, since plenty of
> apps call extract() on those superglobals, but with register_globals
> entirely gone in PHP 6, I suppose that conversion can be moved to the
> extract() c
Stan Vassilev wrote:
Well, that conversion still needs to happen somewhere, since plenty
of apps call extract() on those superglobals, but with
register_globals entirely gone in PHP 6, I suppose that conversion
can be moved to the extract() call.
-Rasmus
Hi,
I'm not sure it needs to happen
Well, that conversion still needs to happen somewhere, since plenty of
apps call extract() on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract() call.
-Rasmus
Hi,
I'm not sure it needs to happen anywhere. Such symbol
Stan Vassilev wrote:
Dots and spaces in variable names are converted to underscores. For
example becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
I'm also using dots for this reason, so I feel your pain. What I ended
Dots and spaces in variable names are converted to underscores. For
example becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
I'm also using dots for this reason, so I feel your pain. What I ended up
doing is convertin
20 matches
Mail list logo
