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
Results for project PHP master, build date 2017-07-28 13:47:43-07:00
commit: f9c3ee9
previous commit:d615a92
revision date: 2017-07-28 22:18:51+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
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
On Fri, Jul 28, 2017 at 11:03 AM, li...@rhsoft.net wrote:
>> 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
Am 28.07.2017 um 16:48 schrieb Andrey Andreev:
Hi,
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 r
Hi,
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 (offsetGet(), but no offsetSet)
>
On Fri, Jul 28, 2017 at 10:11 AM, Rowan Collins wrote:
> On 28 July 2017 14:37:10 BST, "li...@rhsoft.net" wrote:
>>(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
>
> Yes, I
On 28 July 2017 14:37:10 BST, "li...@rhsoft.net" wrote:
>(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
Yes, I only meant that as an absolutely hypothetical "if I had a time
Am 28.07.2017 um 14:48 schrieb Rowan Collins:
On 27 July 2017 18:03:23 BST, "li...@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
On 7/28/2017 3:03 AM, Ryan Jentzsch wrote:
I can't count how many times I've been bitten by this. From the infamous
fractal blog:
"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON t
On 27 July 2017 18:03:23 BST, "li...@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
On 28 July 2017 at 12:46, Andrey Andreev wrote:
>
> This is a long shot, but here's an idea: an OOP API throwing exceptions.
>
> Would require more work both to implement and use, but it would surely
> be less error-prone and there'd be no BC break.
>
Hi Andrey, Yes that would resolve all BC iss
Hi,
On Fri, Jul 28, 2017 at 2:39 PM, Jakub Zelenka wrote:
> On Fri, Jul 28, 2017 at 12:23 PM, Craig Duncan wrote:
>
>> Hi Nikita,
>>
>> Thanks for your input. Would you vote yes for throwing an exception?
>>
>>
> Just to clarify exceptions are no go for 7.x. It would have to be 8.x and
> it woul
On 28 July 2017 at 12:36, Jakub Zelenka wrote:
>
> Also it would break a big amount of code because in case of converting
> errors to exceptions, you start getting a different exception so it would
> have to be handled. I would call the whole proposal just a big BC break
> (I'm aware that we don'
On Fri, Jul 28, 2017 at 12:23 PM, Craig Duncan wrote:
> Hi Nikita,
>
> Thanks for your input. Would you vote yes for throwing an exception?
>
>
Just to clarify exceptions are no go for 7.x. It would have to be 8.x and
it would be a huge BC break so I'm quite confident that this will fail the
vote
On Fri, Jul 28, 2017 at 11:59 AM, Craig Duncan wrote:
> Hi internals.
>
> As my initial thread about introducing warnings to the JSON functions was
> not immediately flooded with disagreement I took the liberty of creating an
> RFC for official discussion.
>
> The proposal is to have `json_encode
Hi Nikita,
Thanks for your input. Would you vote yes for throwing an exception?
On 28 July 2017 at 12:07, Nikita Popov wrote:
>
> Operations that are expected to fail should never generate warnings. We
> should not design functions such that their correct use requires the use of
> the error su
Hi,
On Fri, Jul 28, 2017 at 1:59 PM, Craig Duncan wrote:
> Hi internals.
>
> As my initial thread about introducing warnings to the JSON functions was
> not immediately flooded with disagreement I took the liberty of creating an
> RFC for official discussion.
>
> The proposal is to have `json_enc
On Fri, Jul 28, 2017 at 12:59 PM, Craig Duncan wrote:
> Hi internals.
>
> As my initial thread about introducing warnings to the JSON functions was
> not immediately flooded with disagreement I took the liberty of creating an
> RFC for official discussion.
>
> The proposal is to have `json_encode
Hi internals.
As my initial thread about introducing warnings to the JSON functions was
not immediately flooded with disagreement I took the liberty of creating an
RFC for official discussion.
The proposal is to have `json_encode()` and `json_decode()` raise warnings
whenever a failure occurs, in
I can't count how many times I've been bitten by this. From the infamous
fractal blog:
"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON to decode to—this function is completely
unrel
2017-07-28 8:56 GMT+02:00 Giovanni Giacobbi :
> On 27 July 2017 at 18:00, Craig Duncan wrote:
>
>> On 27 July 2017 at 16:57, Niklas Keller wrote:
>>
>> > It should rather just throw exceptions. Warnings do not really allow
>> error
>> > handling, they just allow error reporting.
>> >
>> >
>> Agr
On 27 July 2017 at 18:00, Craig Duncan wrote:
> On 27 July 2017 at 16:57, Niklas Keller wrote:
>
> > It should rather just throw exceptions. Warnings do not really allow
> error
> > handling, they just allow error reporting.
> >
> >
> Agreed, but I can't see Exceptions passing the vote. Warnings
28 matches
Mail list logo
