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 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 yet, though).
> >
> > The later is certainly misleading. The current naming corresponds to
> > HTML forms.
> >
> > <form method="GET"> -> $_GET
> > <form method="POST"> -> $_POST
>
> Heh, pretty good observation! Didn't think about that. Still not
> buying. $_FORM is derived from "application/x-www-form-urlencoded"
> resp. "multipart/form-data" and $_QUERY is obvious.
Out of curiosity I did some browsing:
- ASP uses Request.QueryString(string name) and Request.Form
- Java Servlets and JSP use ServletRequest.getParameter() for both
- Perl CGI.pm has a param hash for both.
I didn't look really deep though for further specifics :)
So, ASP seems to agree with you, while I see a e difference: In ASP
those are methods which, when used, are always qualified by the Request
Object's name.
A standalone $_QUERY might be confused with the famous $query from
$query= mysql_query().
> > Changing these leads to an incompatibility which can not be emulated
> > (ignoring runkit there is no way for a user to create a custom super
> > global)
>
> Valid point. Though, with a long enough time frame it could be done.
Mind that we are talking about changing each and every PHP application.
Each and every PHP tutorial. Each and every book. Each and every
PHP-related tool. Each and every developers mind. Each and every ...
Phasing out register_globals took us some time.
PHP 4.1, 2001-12-10, $_* introduced and advertised
PHP 4.2, 2002-04-22, register_globals off by default, causing
lots of scream
PHP 5.4, 2012-03-01, register_globals dropped
That's a deprecation process of ten years for a feature which was
relatively easy to emulate (import_request_variables(), extract() etc.)
> > In case that is ignored please mind other related areas, i.e.
> > filter_input() to make sure the resulting new language is consistent.
>
> Yeah, well, there's a lot attached to that cumbersome naming, e.g. all
> *_post_* INI settings etc.
> I should have just resisted proposing that change, but I figured
> testing for backing was cheap.
I think extending the parsing is a good idea and should be done.
And there certainly are quite a few things we would do differently if
PHP was done from scratch, but the days when Rasmus could log in to any
PHP host and apply fixes for new versions are long gone ;-)
This also is a good reminder to take care when adding new features and
to really think those through instead of filling PHP with more and more
stuff (sorry for abusing this thread for the purpose of that rant)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
