Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

Posted by Sara Golemon 
On Fri, Jul 28, 2017 at 11:03 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:
>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <pollita@php.net> wrote:
>>> ftr; I'd vote in favor of several BC breaking things to do with
>>> autoglobals, among them:
>>>
>>> * Make them objects (though ArrayAccess based for less hostile BC
>>> breakage)
>>> * Make most of them read-only (offsetGet(), but no offsetSet)
>>> * Make $_SESSION[...] access produce an error or auto-start the session
>>>
>>> I've seen too many codebases abuse GPCER vars as a generic storage
>>> location because "globals are bad, but this is good because it doesn't
>>> include the word global". As a performance issue, the runtime has to
>>> assume autoglobals are inherently volatile and could change on a whim
>>> at any moment (much like $http_response_headers). Restricting their
>>> mutability would be a win. The request globals could probably also be
>>> optimized fairly significantly.
>>>
>>> If anyone agrees, I'm willing to RFC it. If not, I'll continue living
>>> with it. :D
>>>
>>
>> Yes, please!
>
>
> raise a warning when write to $_SESSION without a session_start()
>
> make a implicit autostart - *for sure not* this would only produce hidden
> errors or later warnings when you rely on session params and introduce more
> problems that it solves because clients don't like the same cookies ith
> different params
>
> make POST/GET/SERVER readonly - only when you refactor a 250000 line code
> base as well as deplyed code which relies on the framework did the right
> thing with them previously :-)
>
>
I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D

1. This would be an 8.0 change as it does represent a significant BC change.
2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2017-07-28 17:11 GMT+02:00 Sara Golemon <pollita@php.net>:
> I'm sure there will be many strong opinions on this, but let's move
> this to a new thread. :D
>
> 1. This would be an 8.0 change as it does represent a significant BC change.
> 2. We can discuss the possibility of INI options or other mitigation
> strategies for misbehaving code bases (and they do exist).
> 3. I'm definitely not decided on what I'd like from default session
> behavior. An error isn't out of the question, for sure.

I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Paul Jones
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 28, 2017 06:50PM
> On Jul 28, 2017, at 10:11, Sara Golemon <pollita@php.net> wrote:
>
> 3. I'm definitely not decided on what I'd like from default session
> behavior. An error isn't out of the question, for sure.

If this kind of big change is being contemplated, I would very much be in favor of decoupling the various combined elements of sessions. In particular, decoupling the auto-reading and auto-sending of cookies from the storage interactions.

Also, the "request" extension (and its related RFC) may have some use here, as it attempts to address the readable nature of superglobals.

- http://pecl.php.net/package/request
- https://wiki.php.net/rfc/request_response


--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lists@rhsoft.net
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 28, 2017 06:50PM
Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
> 2017-07-28 17:11 GMT+02:00 Sara Golemon <pollita@php.net>:
>> I'm sure there will be many strong opinions on this, but let's move
>> this to a new thread. :D
>>
>> 1. This would be an 8.0 change as it does represent a significant BC change.
>> 2. We can discuss the possibility of INI options or other mitigation
>> strategies for misbehaving code bases (and they do exist).
>> 3. I'm definitely not decided on what I'd like from default session
>> behavior. An error isn't out of the question, for sure.
>
> I for one thing it makes a lot of sense to make superglobals
> read-only, writing to them seems more like a hack anyway and should be
> avoided

wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to cosindr changes
breaking a ton of perfect working code

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rick Widmer
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 28, 2017 08:00PM
On 7/28/2017 10:42 AM, lists@rhsoft.net wrote:
>
>
> Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
>> 2017-07-28 17:11 GMT+02:00 Sara Golemon <pollita@php.net>:
>>> I'm sure there will be many strong opinions on this, but let's move
>>> this to a new thread. :D
>>>
>>> 1. This would be an 8.0 change as it does represent a significant BC
>>> change.
>>> 2. We can discuss the possibility of INI options or other mitigation
>>> strategies for misbehaving code bases (and they do exist).
>>> 3. I'm definitely not decided on what I'd like from default session
>>> behavior. An error isn't out of the question, for sure.
>>
>> I for one thing it makes a lot of sense to make superglobals
>> read-only, writing to them seems more like a hack anyway and should be
>> avoided
>
> wrong question!
>
> the right questions are
>
> * are you fored to do so
> * are you harmed by the possibility
>
> and only if you can answer both with "yes" it's worth to cosindr changes
> breaking a ton of perfect working code
>

What he said. That would break almost everything I've written.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fr, 2017-07-28 at 11:11 -0400, Sara Golemon wrote:
> I'm sure there will be many strong opinions on this, but let's move
> this to a new thread. :D

Language-wise, I think, refactoring that system would be good. I guess
a refactoring is a register_globals-like project, which took 10 years
from first deprecations to final removal, since many people abuse it
and parameter handling is core to PHP.

For read-only access we already have an API: filter_input() etc., maybe
the interface could be made "nicer." GitHub shows 267,811 hits for
that, but only few "real" "productive" cases. From tutorials etc. this
doesn't seem to be widely accepted.
https://github.com/search?l=PHP&p=1&q=filter_input&type=Code&utf8=%E2%9
C%93

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Sara,

>>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <pollita@php.net>
>wrote:
>>>> ftr; I'd vote in favor of several BC breaking things to do with
>>>> autoglobals, among them:
>>>>
>>>> * Make them objects (though ArrayAccess based for less hostile BC
>>>> breakage)
>>>> * Make most of them read-only (offsetGet(), but no offsetSet)
>>>> * Make $_SESSION[...] access produce an error or auto-start the
>session

Yep, this is pretty much what I had in mind when I made that passing remark, but didn't want to derail the thread. Now it has its own thread, however, I'm going to argue against myself and say why I think this is the wrong direction. ;)

The obvious downside of changing request vars to read only is the huge body of code that writes to them. This isn't all bad code: as rhsoft points out, testing any code that *reads* those vars necessarily requires the harness to write to them; and a common way to *prevent* reading them is to overwrite them with empty values.

More importantly, though, it's papering over the problem, which is that request information shouldn't be global. There are other barriers to a threaded, event-based SAPI becoming core and default, but a scoped request representation would be high up the todo list.

There was mention a while ago of discussion in the Python community of replacing WSGI with an even more flexible interface for the HTTP2 era, supporting worker and server push models as well as request-response. The suggestion was that PHP could learn from or even collaborate on that model. Does anyone know its status?

Obviously, that's a much more ambitious project, but if we're talking 10 years to phase in a breaking change, it would be good to at least attempt some future-proofing, rather than just adding a few restrictions which were missed 10 years ago, and implicitly extending the lifetime of the concept of global request data.

On a slight tangent, I consider $_SERVER to be a broken pile of "we'll just shove this in here and hope for the best", and I will oppose any attempt to convert it into an object which doesn't reorganize its keys to be sane, documented, and as cross-platform as the SAPI layer can make it. :P

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Jul 28, 2017 at 11:03 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:
> make POST/GET/SERVER readonly - only when you refactor a 250000 line code
> base as well as deplyed code which relies on the framework did the right
> thing with them previously :-)

Are you advocating for read-only or leaving them read-write? I can't tell.


Every language feature in every language can be abused. Having
sufficient documentation helps avoid unwanted abuse.

As a brief demonstration of how that plays out, a quick search on the
website turned up:

http://us3.php.net/manual/en/reserved.variables.request.php

There isn't an example usage pattern there nor any
restrictions/recommendations on use and the top comment has 97 upvotes.
The first thing that person's code does is freely set new values in
multiple superglobals without sufficient explanation that doing so is a
bad idea. Therefore, drive-by PHP users can derive that it must be okay
to store general-purpose information into a superglobal. "This must be
the right way to do things since it has over 10 times as many upvotes as
the next comment on the page."


While I'm for read-write superglobals, I will, of course, live with
whatever is decided upon and adapt accordingly. Making some
documentation adjustments seems like a simpler thing to do than a BC break.

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 28 July 2017 at 16:11, Sara Golemon <pollita@php.net> wrote:

> ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:
>
>* Make them objects (though ArrayAccess based for less hostile BC breakage)


Why objects?

Although these are kind of just about related things they don't
require being in a class/interface.

Designing classes/interfaces to be correct the first time is a really
difficult thing to do, and then maintaining classes/interfaces is hard
as any change to a method is a BC break.

I feel pretty strongly that 'just' using a set of function to read the
data would be the correct thing to do as:

i) they are easier to maintain.

ii) They allow people to composite them into objects easily.

iii) They're simpler to use in code.

> I've seen too many codebases abuse GPCER vars as a generic storage
> Restricting their mutability would be a win.

Or we could just leave the global mutable variables alone, and just
introduce the new set of functions to get the original unmodified
data, which would be inherently read-only.

That allows everyone who wants to move away from mutable state to do
so, leaves current applications working, and we can have the
lovely-and-not-at-all-depressing "WHY ARE YOU TERRIBLE PEOPLE BREAKING
WORKING CODE!!1!" conversation as a separate discussion; one that
doesn't get in the way of allowing people who'd prefer to move forward
with saner global state.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lists@rhsoft.net
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 29, 2017 03:10PM
Am 29.07.2017 um 08:47 schrieb Thomas Hruska:
> On Fri, Jul 28, 2017 at 11:03 AM, lists@rhsoft.net <lists@rhsoft.net>
> wrote:
>> make POST/GET/SERVER readonly - only when you refactor a 250000 line code
>> base as well as deplyed code which relies on the framework did the right
>> thing with them previously :-)
>
> Are you advocating for read-only or leaving them read-write? I can't tell

how comes?

-------- Weitergeleitete Nachricht --------
Betreff: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
Datum: Fri, 28 Jul 2017 18:42:16 +0200
Von: lists@rhsoft.net <lists@rhsoft.net>
An: internals@lists.php.net

Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
> I for one thing it makes a lot of sense to make superglobals
> read-only, writing to them seems more like a hack anyway and should be
> avoided

wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to consider
changes breaking a ton of perfect working code

-------- Weitergeleitete Nachricht --------
Betreff: Re: [PHP-DEV] session_start() should not reset $_SESSIOn if
it's not empty
Datum: Fri, 28 Jul 2017 15:37:10 +0200
Von: lists@rhsoft.net <lists@rhsoft.net>
An: internals@lists.php.net

Am 28.07.2017 um 14:48 schrieb Rowan Collins:
> On 27 July 2017 18:03:23 BST, "lists@rhsoft.net" <lists@rhsoft.net>
wrote:
>> if that could work in the way that session_start() keeps the current
>> state of $_SESSION if not empty it would be possible to put the
>> APCU-Read and if exit($apcu_content); before session_start() which
>> would
>> gain another 30% performance
>
> I think that behaviour would confuse more people than it would help.
If anything, it should be an error to access $_ SESSION if no session is
currently open - if there is no session, the array has no meaning.
(Arguably, all the other superglobals should be read only for the same
reason, but that would be a huge break now.)

make them readonly would break my whole codebase including autotests and
code-coverage tools because it is legit to as example fill
$_SERVER['SERVER_NAME'] with specific informations to define a straight
behavior when running in cli-test-mode instead wrap every basic thing in
function calls - at the curretn state a core-cms cache-hit has a total
of 32 funtion calls including PHP internal ones

hence that 3 bugreport are becoming a MAJOR PROBLEM because the system
itself is so fast that under load after a short time you get problems
with dattabase connections and with persistent connections because of
the third one after the load is gone any strict-typed application jsut
breaks horrible

https://bugs.php.net/bug.php?id=74971
https://bugs.php.net/bug.php?id=74970
https://bugs.php.net/bug.php?id=74967

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Rowan,

Rowan Collins wrote:
> On a slight tangent, I consider $_SERVER to be a broken pile of "we'll just shove this in here and hope for the best", and I will oppose any attempt to convert it into an object which doesn't reorganize its keys to be sane, documented, and as cross-platform as the SAPI layer can make it. :P

$_SERVER makes sense to me, its content is what the CGI environment
variables would be (or are, if you're actually using CGI in 2017). Those
are standardised.

I don't know if the PHP documentation acknowledges this, though. Its
members certainly aren't well-documented…

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Sara,

I'd just like to add that if we were going to make BC-breaking changes
to superglobals in PHP 8, we might as well also get rid of the name
mangling on keys for $_GET, $_POST and $_REQUEST at the same time
("foo.x" becomes "foo_x" etc, because we used to have register_globals
and needed clean variable names).

Thanks for bringing this up!
--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Jul 29, 2017, at 05:27, Dan Ackroyd <danack@basereality.com> wrote:
>
> Designing classes/interfaces to be correct the first time is a really
> difficult thing to do, and then maintaining classes/interfaces is hard
> as any change to a method is a BC break.

Having done it several times before in userland helps. Presenting the superglobals as read-only properties does the trick for the `request` extension; it's even simpler than using methods.


--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds <ajf@ajf.me> wrote:
> I'd just like to add that if we were going to make BC-breaking changes to
> superglobals in PHP 8, we might as well also get rid of the name mangling on
> keys for $_GET, $_POST and $_REQUEST at the same time ("foo.x" becomes
> "foo_x" etc, because we used to have register_globals and needed clean
> variable names).
>
Excellent point. I always forget this is a thing we do and it needs
to die. Even if we leave everything else aboue the super globals
alone, this one thing should die in PHP 8.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 29 July 2017 15:05:57 BST, Andrea Faulds <ajf@ajf.me> wrote:
>Hi Rowan,
>
>Rowan Collins wrote:
>> On a slight tangent, I consider $_SERVER to be a broken pile of
>"we'll just shove this in here and hope for the best", and I will
>oppose any attempt to convert it into an object which doesn't
>reorganize its keys to be sane, documented, and as cross-platform as
>the SAPI layer can make it. :P
>
>$_SERVER makes sense to me, its content is what the CGI environment
>variables would be (or are, if you're actually using CGI in 2017).
>Those
>are standardised.

But what does a standardised CGI variable list have to do with anything when you're running under an Apache module, or one of our two fast-cgi SAPIs, let alone if we ever want event-based or asynchronous SAPIs to be a thing?

If you want to know the URL the user requested, you have to know about the subtle differences between half a dozen different variables which will be populated differently, or not at all, depending on your configuration. Some of this is inevitable because there are too many different ways of achieving the same thing, but at least some of it is known by the SAPI, which nonetheless blindly populates $_SERVER with whatever the hosting server provided.

And talking of name mangling, CGI mangles the request HTTP headers in its own quirky way, when they should just be a structure of their own separate from this generic environment. That particular quirk can even cause security problems, IIRC.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon wrote:
> On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds <ajf@ajf.me> wrote:
>> I'd just like to add that if we were going to make BC-breaking changes to
>> superglobals in PHP 8, we might as well also get rid of the name mangling on
>> keys for $_GET, $_POST and $_REQUEST at the same time ("foo.x" becomes
>> "foo_x" etc, because we used to have register_globals and needed clean
>> variable names).
>>
> Excellent point. I always forget this is a thing we do and it needs
> to die. Even if we leave everything else aboue the super globals
> alone, this one thing should die in PHP 8.

Come to think of it, can we fix $_FILES while we're at it? :p

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Jul 29, 2017, at 11:58, Andrea Faulds <ajf@ajf.me> wrote:
>
> Come to think of it, can we fix $_FILES while we're at it? :p

Not to be a broken record here, but this is something the `request` extension does as well.

In other words, a starting point for a lot of this work already exists.


--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!

> I for one thing it makes a lot of sense to make superglobals
> read-only, writing to them seems more like a hack anyway and should be
> avoided

I've seen scenarios where it is very useful. Sure, you can always build
another layer of indirection and solve it this way, but it's just making
people do more work for no reason. I don't see any problem that would solve.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!


> On a slight tangent, I consider $_SERVER to be a broken pile of
> "we'll just shove this in here and hope for the best", and I will
> oppose any attempt to convert it into an object which doesn't
> reorganize its keys to be sane, documented, and as cross-platform as
> the SAPI layer can make it. :P

You cannot make it cross-platform, as it is specifically made for
environment consisting the current platform, making it cross-platform
would just force you to create yet another one which contains the bits
that didn't fit into "cross-platform".

As for sane/documented, documenting every quirk of every system is a
herculean task, and we don't have too much control about how (in)sane
each OS environment could get.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!

> I'd just like to add that if we were going to make BC-breaking changes
> to superglobals in PHP 8, we might as well also get rid of the name
> mangling on keys for $_GET, $_POST and $_REQUEST at the same time

That's a good point. We definitely should get rid of this one, it adds
absolutely nothing now. It might expose some security issues though in
bad scripts that rely on mangling for safety while recomposing URLs
(which of course they shouldn't but... sigh...)

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi

2017-07-29 22:17 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:
> I've seen scenarios where it is very useful. Sure, you can always build
> another layer of indirection and solve it this way, but it's just making
> people do more work for no reason. I don't see any problem that would solve.

Sure it seems useful, but I see it more as a hack if you are just
writing to superglobals anyway, if you need to change something you
should do that with your own logic instead.

If its something simple such as your code assumes $_GET['id'] always
is available, then either write it to a temp variable.

I know many applications nowadays are not written with an excess
amount of globals everywhere, but writing to a global without
explicitly declaring you want to, can cause some hard to debug cases
if one function modifies a global and another assumes an unmodified
value. I'd like to see that gone.


--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 30, 2017 02:30AM
Hi!

> Sure it seems useful, but I see it more as a hack if you are just
> writing to superglobals anyway, if you need to change something you
> should do that with your own logic instead.

That's what I said - you can always add a layer of indirection. But why?
What is so sacred in those variables that writing into them is taboo and
writing into intermediate layer is OK?

> If its something simple such as your code assumes $_GET['id'] always
> is available, then either write it to a temp variable.

Again, could do it, but why? What is so special in '_GET' that is not in
temp variable? Why make me do extra work?

> I know many applications nowadays are not written with an excess
> amount of globals everywhere, but writing to a global without
> explicitly declaring you want to, can cause some hard to debug cases
> if one function modifies a global and another assumes an unmodified
> value. I'd like to see that gone.

Request context is a global state. It is a legit global state -
everything within the request is executed in the context of the request.
If you put this global state into some kind of intermediate layer
instead of _GET, you would have absolutely the same global state issues.
You can write your app so that it extracts data from global state into
local state and does not depend on it, but this has nothing to do with
_GET itself - you could do it very well without changing anything with
_GET. Changing _GET does not solve the issues if you use global state,
and the issues do not exist if you don't.
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lists@rhsoft.net
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 30, 2017 07:00AM
Am 30.07.2017 um 01:35 schrieb Kalle Sommer Nielsen:
> 2017-07-29 22:17 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:
>> I've seen scenarios where it is very useful. Sure, you can always build
>> another layer of indirection and solve it this way, but it's just making
>> people do more work for no reason. I don't see any problem that would solve.
>
> Sure it seems useful, but I see it more as a hack if you are just
> writing to superglobals anyway, if you need to change something you
> should do that with your own logic instead.

well, you can do that in your code as you like

> If its something simple such as your code assumes $_GET['id'] always
> is available, then either write it to a temp variable.

or just leave that decision to the developer

> I know many applications nowadays are not written with an excess
> amount of globals everywhere, but writing to a global without
> explicitly declaring you want to, can cause some hard to debug cases
> if one function modifies a global and another assumes an unmodified
> value. I'd like to see that gone

frankly are you forced to use it?

PHP has really more important possible improvements than breaking others
code just because you like to see something gone - in my code i write to
$_SERVER in a central point to fix the issue that you developers missed
to standardize what is available there 15 years ago on differnet
operating systems/SAPI's

hence my code runs since 15 years ago without spit checks around all
over the codebase and now you "like to see that gone"?

frankly i like the "what can i do to break others code" attitude of some
people go and if you like to break something for a good reason fix
inconsistences in the param oders of some database unctions - but better
don't because i fear your proposed solution would be "why not remove
anything except PDO"

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -----Original Message-----
> From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of Kalle
> Sommer Nielsen
> Sent: Sunday, July 30, 2017 2:36 AM
> To: Stanislav Malyshev <smalyshev@gmail.com>
> Cc: Sara Golemon <pollita@php.net>; PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something
> about session_start...)
>
> Hi
>
> 2017-07-29 22:17 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:
> > I've seen scenarios where it is very useful. Sure, you can always
> > build another layer of indirection and solve it this way, but it's
> > just making people do more work for no reason. I don't see any problem that
> would solve.
>
> Sure it seems useful, but I see it more as a hack if you are just writing to
> superglobals anyway, if you need to change something you should do that with
> your own logic instead.

So we agree that it at least seems useful, why do you see it as a hack? What real downsides does it have, that are so overwhelming as to require a change to this behavior that's been with us for countless years and is most likely deeply engrained into many applications?

> I know many applications nowadays are not written with an excess amount of
> globals everywhere, but writing to a global without explicitly declaring you
> want to, can cause some hard to debug cases if one function modifies a global
> and another assumes an unmodified value. I'd like to see that gone.

I don't recall ever bumping into users complain about this. Do we have examples where this behavior caused a real world bug or security issue?

To me, if you don't want to write into super globals, that's entirely your right - and you can enforce that in your organization via a coding standard. IMHO, there's no need to change the language (in a far reaching way) to force you to do that.

Zeev
> -----Original Message-----
> From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Saturday, July 29, 2017 5:29 PM
> To: Andrea Faulds <ajf@ajf.me>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Re: Changes to SuperGlobals for PHP 8 (was: something
> about session_start...)
>
> On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds <ajf@ajf.me> wrote:
> > I'd just like to add that if we were going to make BC-breaking changes
> > to superglobals in PHP 8, we might as well also get rid of the name
> > mangling on keys for $_GET, $_POST and $_REQUEST at the same time
> > ("foo.x" becomes "foo_x" etc, because we used to have register_globals
> > and needed clean variable names).
> >
> Excellent point. I always forget this is a thing we do and it needs to die. Even if
> we leave everything else aboue the super globals alone, this one thing should
> die in PHP 8.

Agreed.

Zeev
Rowan Collins
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 30, 2017 08:10PM
On 30 July 2017 01:18:56 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Request context is a global state. It is a legit global state -
>everything within the request is executed in the context of the
>request.

This is true within the context of the current "shared nothing" design of PHP. There has been talk - and indeed existing implementations - of a more event-based system, where this state would no longer be naturally global in any sense. But as I mentioned before, that ought to lead us to designing a much more radical new representation, rather than just playing around with the current superglobals.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 29 July 2017 21:22:30 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> On a slight tangent, I consider $_SERVER to be a broken pile of
>> "we'll just shove this in here and hope for the best", and I will
>> oppose any attempt to convert it into an object which doesn't
>> reorganize its keys to be sane, documented, and as cross-platform as
>> the SAPI layer can make it. :P
>
>You cannot make it cross-platform, as it is specifically made for
>environment consisting the current platform, making it cross-platform
>would just force you to create yet another one which contains the bits
>that didn't fit into "cross-platform".


I'm fine with having an interface for access to low-level, platform specific details, but that's not how I have mostly seen $_SERVER being used. Mostly, people want specific details, like the requested URL and the HTTP headers sent, all of which should be trivial for SAPIs to provide in a standard, user-friendly format. I wouldn't be surprised if some SAPIs are carefully mangling the data into fake CGI format, only for userland code to unmangle it for actual use.

My point was that if we were considering a compatibility break anyway, we should look at separating out those common use cases into something higher level. Having done that, we could even allow the low-level "raw server vars" (not under the name $_SERVER) to drift even further apart, rather than sticking to CGI rules from 20+ years ago.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 30, 2017 09:20PM
Hi!

> This is true within the context of the current "shared nothing"
> design of PHP. There has been talk - and indeed existing
> implementations - of a more event-based system, where this state
> would no longer be naturally global in any sense. But as I

That's fine - but in that design, you should not be using environment
that is true global. You should be using something else. As such,
there's no reason to mess with superglobals.

> radical new representation, rather than just playing around with the
> current superglobals.

And I have no problem with that. As I said, you can always build a layer
of indirection that suits your particular design, and many frameworks do
just that. But to enable this, the language layer - the bottom layer -
should be flexible, and it is such right now.
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 30, 2017 09:30PM
Hi!

> My point was that if we were considering a compatibility break
> anyway, we should look at separating out those common use cases into
> something higher level.

I'm completely in agreement with you here, except for "compatibility
break" part. The good news is that you do not need any compatibility
breaks! If you want to create API that allows easy standardized access
to the common denominator of web requests - and I do not disagree it
would be a good thing! - you do not need to change _SERVER. In fact,
there's no reason to change it as if you turn _SERVER into this layer,
this would only lead to creating _REAL_SERVER containing what _SERVER
used to.

Instead, we could just create this layer - either as $_SAPI, or as
function collection, or as object if people want it that way - does not
matter, really - and let it live by itself, not encumbered by any
concerns about BC and not hurting any existing apps. I do not see any
downside to this approach, do you?

> Having done that, we could even allow the low-level "raw server vars"
> (not under the name $_SERVER) to drift even further

Why not under the name _SERVER?

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
July 31, 2017 01:00AM
On 30 July 2017 20:21:01 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi!
>
>> My point was that if we were considering a compatibility break
>> anyway, we should look at separating out those common use cases into
>> something higher level.
>
>I'm completely in agreement with you here, except for "compatibility
>break" part. The good news is that you do not need any compatibility
>breaks! If you want to create API that allows easy standardized access
>to the common denominator of web requests - and I do not disagree it
>would be a good thing! - you do not need to change _SERVER.

A good point. Of course, "if" doesn't have to be symmetrical, so perhaps I should say that if we plan to break compatibility, we should definitely do this; if we don't plan to, we should maybe do it anyway.


>> Having done that, we could even allow the low-level "raw server vars"
>> (not under the name $_SERVER) to drift even further
>
>Why not under the name _SERVER?

In general, I always think that when splitting something, you should rename both parts, not keep one. Code using the retained name will continue to partly work but have odd bugs, rather than completely failing until someone reviews which replacement is appropriate.

But in reality, you might want to keep $_SERVER around for compatibility anyway, so there'd be no point having 3 different versions of the same thing. The only advantage of a new name at that point would be if we decided to get rid of the shared nothing, global request state model.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login