On 30 July 2017 20:21:01 BST, Stanislav Malyshev 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 "compatibilit
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 compati
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 sh
On 29 July 2017 21:22:30 BST, Stanislav Malyshev 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, docume
On 30 July 2017 01:18:56 BST, Stanislav Malyshev 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 -
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of Kalle
> Sommer Nielsen
> Sent: Sunday, July 30, 2017 2:36 AM
> To: Stanislav Malyshev
> Cc: Sara Golemon ; PHP internals
> Subject: Re: [PHP-DEV] Changes to SuperGlobals for
Am 30.07.2017 um 01:35 schrieb Kalle Sommer Nielsen:
2017-07-29 22:17 GMT+02:00 Stanislav Malyshev :
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 a
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
Hi
2017-07-29 22:17 GMT+02:00 Stanislav Malyshev :
> 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 usef
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
pe
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 mak
On 29 July 2017 15:05:57 BST, Andrea Faulds 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
> On Jul 29, 2017, at 05:27, Dan Ackroyd 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. P
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 t
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: li...@rhsoft.net
An: internals@lists.php.net
Am 28.07.2017 um
On 28 July 2017 at 16:11, Sara Golemon 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
r
On Fri, Jul 28, 2017 at 11:03 AM, li...@rhsoft.net wrote:
make POST/GET/SERVER readonly - only when you refactor a 25 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-writ
Hi Sara,
>>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon
>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 (offs
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 f
On 7/28/2017 10:42 AM, li...@rhsoft.net wrote:
Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
2017-07-28 17:11 GMT+02:00 Sara Golemon :
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 sig
Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
2017-07-28 17:11 GMT+02:00 Sara Golemon :
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 possib
> On Jul 28, 2017, at 10:11, Sara Golemon 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
2017-07-28 17:11 GMT+02:00 Sara Golemon :
> 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
> strate
23 matches
Mail list logo
