Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not
100% confident with the latter
On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out
On 2 October 2013 09:17, Alexey Zakhlestin indey...@gmail.com wrote:
3. expose body-parsers via php-level API
+1. Hell, yes! Something like +1000, actually ;)
Uhmmm... I actually meant an interal API not userland :)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing
Hi,
wouldn’t $_BODY be better - since it is the request body?
$_FORM is imho not very clear, since you can send data to $_POST without using
a form.
--
Cheers
Jannik
Am Mittwoch, 2. Oktober 2013 um 09:17 schrieb Alexey Zakhlestin:
On 02.10.2013, at 10:59, Michael Wallner m...@php.net
On 2 October 2013 09:25, Jannik Zschiesche he...@apfelbox.net wrote:
Hi,
wouldn’t $_BODY be better - since it is the request body?
$_FORM is imho not very clear, since you can send data to $_POST without
using a form.
I had it, but I'm not sure $_BODY fits either, because it should be an
On 02.10.2013, at 11:24, Michael Wallner m...@php.net wrote:
On 2 October 2013 09:17, Alexey Zakhlestin indey...@gmail.com wrote:
3. expose body-parsers via php-level API
+1. Hell, yes! Something like +1000, actually ;)
Uhmmm... I actually meant an interal API not userland :)
well,
On Sat, Sep 28, 2013 at 3:44 PM, Lior Kaplan lio...@zend.com wrote:
On Sat, Sep 28, 2013 at 12:57 PM, Derick Rethans der...@php.net wrote:
And bug 31347 is that was a fix for a specific issue on Windows:
https://bugs.php.net/bug.php?id=31347
The patch originates in Debian, and I can assure
On 2 October 2013 11:39, Lior Kaplan lio...@zend.com wrote:
On Sat, Sep 28, 2013 at 3:44 PM, Lior Kaplan lio...@zend.com wrote:
On Sat, Sep 28, 2013 at 12:57 PM, Derick Rethans der...@php.net wrote:
And bug 31347 is that was a fix for a specific issue on Windows:
Le 2 octobre 2013 à 07:59, Michael Wallner m...@php.net a écrit :
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase
Le 2 octobre 2013 à 10:58, Michael Wallner m...@php.net a écrit :
On 2 October 2013 11:56, Andrea Faulds a...@ajf.me wrote:
Backwards compatibility matters, so we should keep $_GET and $_POST but add
these as better aliases for them.
That's why I said phase out... or is it a german
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
I propose to phase out $_GET and name it $_QUERY and
I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
may not be 100% accurate, _most_ people are used to their
On 02.10.2013, at 15:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 08:31, Michael Wallner m...@php.net wrote:
I had it, but I'm not sure $_BODY fits either, because it should be an
array. Currently only form data fits the purpose of de-serialisation
of a request body.
Not so
On 2 October 2013 12:00, Andrea Faulds a...@ajf.me wrote:
Le 2 octobre 2013 à 10:58, Michael Wallner m...@php.net a écrit :
On 2 October 2013 11:56, Andrea Faulds a...@ajf.me wrote:
Backwards compatibility matters, so we should keep $_GET and $_POST but add
these as better aliases for them.
On 2 October 2013 13:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
I propose to phase out $_GET and name it $_QUERY and
I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
Le 2 octobre 2013 à 13:27, Michael Wallner m...@php.net a écrit :
On 2 October 2013 13:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
You certainly won't be able to remove $_GET / $_POST (implied by
phase out) in any 5.x release, it's
On Wed, 2013-10-02 at 14:50 +0100, Andrea Faulds wrote:
Le 2 octobre 2013 à 13:27, Michael Wallner m...@php.net a écrit :
On 2 October 2013 13:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
You certainly won't be able to remove $_GET
UPDATE: I figured out number 2. Maybe I had an extra text node in there,
but now it's working.
Can someone help with the others?
-John
On 9/26/2013 8:12 PM, John Stokes wrote:
Well, fine then.
I'm trying to understand the mechanics behind XMLReader::next() and
XMLReader::read()
Given an
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out $_POST
On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase
The superglobals are a hopelessly poor abstraction. Can we stop trying to
put the proverbial gold ring in the pig's snout on this?
While a change to `$_QUERY` and `$_BODY` would undoubtedly be an
improvement I don't think the massive BC breaks that would result are
justified by simply improving
On 02.10.2013 17:29, Daniel Lowrey wrote:
The superglobals are a hopelessly poor abstraction. Can we stop trying to
put the proverbial gold ring in the pig's snout on this?
[...]
Something like the following would be an infinitely superior solution:
interface HttpRequest {
function
Hi internals!
I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to whether you
consider this feasible.
So, first off, this is how PHP currently behaves:
?php setlocale(LC_ALL, 'de_DE');
var_dump((string) 3.14);
//
Further, I propose to remove the POST method restriction for handling
request bodies and solely rely on the content type to trigger the
parser(s). (*)
+1
This would solve the with parsing multi-form data with PUT requests (and
possibly any future method types), thus enabling full REST support :)
On 10/02/2013 10:26 AM, Nikita Popov wrote:
Hi internals!
I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to whether you
consider this feasible.
So, my suggestion is to change the (string) cast to always use . as the
On 2 October 2013 16:10, Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose
On 2 October 2013 17:15, Nikita Popov nikita@gmail.com wrote:
On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I
On 2 October 2013 10:57, Christopher Jones christopher.jo...@oracle.com wrote:
On 10/02/2013 10:26 AM, Nikita Popov wrote:
I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to whether you
consider this feasible.
I'd like
On Wed, Oct 2, 2013 at 8:02 PM, Michael Wallner m...@php.net wrote:
There are already parsers for application/x-www-form-urlencoded and
multipart/form-data in the core. One could think of providing an API
to add content type handlers from extensions, ext/json may be an
example, like it
Hi,
I was wondering why stream API has been changed in this commit:
https://github.com/php/php-src/commit/92d27ccb0574f901a107409a7fec92888fa2b82f
Basically all char pointers have been constified. The thing is that this
commit leads to compilation warning for many extensions.
In my case I use
On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out
On Wed, Oct 2, 2013 at 7:57 PM, Christopher Jones
christopher.jo...@oracle.com wrote:
I'd like to see float/double casts recognize the locale's decimal
separator. It's perfectly fine in Oracle DB for numbers to be
inserted/fetched with , (or any other character) as the decimal
separator:
Am I the only one thinking this, is there actually someone who is using
__construct as re-initialising method?
php doesn't invoke the parent's constructor from the subclass if the
subclass also have a constructor, so in that case calling
parent::__construct() manually is your only option
+1! This guy is epic!
On Mon, Sep 30, 2013 at 10:56 PM, Daniel Lowrey rdlow...@gmail.com wrote:
Good day, security-conscious internals people.
I'm ready to float an RFC + patch for default SSL/TLS peer verification and
TLSv1.1/TLSv1.2 support as mentioned in this thread:
On Wed, 2013-10-02 at 19:59 +0200, Michael Wallner wrote:
On 2 October 2013 16:10, Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do
My understanding is that the const triggers some optimizations because the
compiler better understands how the variables are used.
I'm not sure what degree of a difference it makes, but I'm always a fan of
using const if it's appropriate.
Perhaps your effort is better spent modifying the
Le 02/10/2013 20:41, Jakub Zelenka a écrit :
Hi,
I was wondering why stream API has been changed in this commit:
https://github.com/php/php-src/commit/92d27ccb0574f901a107409a7fec92888fa2b82f
Basically all char pointers have been constified. The thing is that this
commit leads to
36 matches
Mail list logo
