Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

This is only part of a thread. view whole thread
  108471
February 11, 2020 12:42 albertcasademont@gmail.com (Albert Casademont)
This is very interesting, thanks!

Would it make sense to also add an INI setting to disable superglobals and
response functions?


On Tue, Feb 11, 2020 at 10:34 AM Jan Schneider <jan@horde.org> wrote:

> > Zitat von Paul M. Jones <pmjones@pmjones.io>: > > > Hi Internals, > > > > After a couple of years of incubation, I am happy to offer a second > > version of this RFC: > > > > https://wiki.php.net/rfc/request_response > > > > It proposes an object-oriented approach around request and response > > functionality already existing in PHP, in order to reduce the > > global-state problems that come with superglobals and the various > > response-related functions. > > I like this proposal a lot, since it provides a clear, concise > interface to these commonly uses, yet inconveniant to use, existing > functions and variables without having to always use a full-featured > userland library. > Speaking of interfaces: since you suggest using decoration and > composition over extension for ServerResponse, I am missing a > ServerResponseInterface, so that you can easily typehint such userland > decorators. > > -- > Jan Schneider > The Horde Project > https://www.horde.org/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  108476
February 11, 2020 12:59 harry@rhsoft.net ("Reindl Harald (privat)")
Am 11.02.20 um 13:42 schrieb Albert Casademont:
> This is very interesting, thanks! > > Would it make sense to also add an INI setting to disable superglobals and > response functions?
no because changing basic language behavior that way is not helpful for code meant to run everywhere and not stop working just because tomorrow someone changed a random ini setting
  108491
February 11, 2020 17:22 albertcasademont@gmail.com (Albert Casademont)
On Tue, Feb 11, 2020 at 1:59 PM Reindl Harald (privat) <harry@rhsoft.net>
wrote:

> > > Am 11.02.20 um 13:42 schrieb Albert Casademont: > > This is very interesting, thanks! > > > > Would it make sense to also add an INI setting to disable superglobals > and > > response functions? > > no because changing basic language behavior that way is not helpful for > code meant to run everywhere and not stop working just because tomorrow > someone changed a random ini setting >
That could be said for all INI settings: yes they can break things if you touch them without knowing what they do. I think it might make sense to be able to disable superglobals and response functions if your codebase is committed to using the new classes, much like the old "register_globals" did. Why pollute the global namespace if you don't need them?
  108523
February 12, 2020 22:09 pmjones@pmjones.io ("Paul M. Jones")
Hi Albert,

> On Feb 11, 2020, at 11:22, Albert Casademont <albertcasademont@gmail.com> wrote: > >> Am 11.02.20 um 13:42 schrieb Albert Casademont: >> >>> This is very interesting, thanks! >>> >>> Would it make sense to also add an INI setting to disable superglobals >>> and response functions? >> >> no because changing basic language behavior that way is not helpful for >> code meant to run everywhere and not stop working just because tomorrow >> someone changed a random ini setting > > That could be said for all INI settings: yes they can break things if you > touch them without knowing what they do. > > I think it might make sense to be able to disable superglobals and response > functions if your codebase is committed to using the new classes, much like > the old "register_globals" did. Why pollute the global namespace if you > don't need them?
I share Harald's opinion here. I think a .ini setting to disable superglobals and the response-related functions is out-of-scope for this RFC. -- Paul M. Jones pmjones@pmjones.io 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