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, internals,
> On 26 Jul 2017, at 22:57, Nicolas Grekas wrote:
>
> I'm hitting more and more the GC threshold in projects I work on (the "10k
> roots" one), leading to high CPU usage. Usually, the GC finds nothing to
> clean, so this is just a waste of CPU.
More and more php frameworks use ob
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!
> 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
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
Hi!
> Lately there was a discovering about some files causing size growth
> of the release tarballs
> https://github.com/php/php-src/commit/469206c84e502e3e349655b802899d5e4d560f72
> . Usually we strive to keep tarballs as small as possible and avoid
> disproportional growth of the size. This case
Andrea Faulds schrieb am Sa., 29. Juli 2017, 18:55:
> Hi Craig,
>
> Craig Duncan wrote:
> > On 29 July 2017 at 15:16, Andrea Faulds wrote:
> >
> >> Could we not simply make it a flag? e.g.
> >>
> >> $bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
> >> $baz = json_decode($bar, false, 512
> On Jul 29, 2017, at 11:58, Andrea Faulds 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.
Sara Golemon wrote:
On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds 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" become
Hi Craig,
Craig Duncan wrote:
On 29 July 2017 at 15:16, Andrea Faulds wrote:
Could we not simply make it a flag? e.g.
$bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
$baz = json_decode($bar, false, 512, JSON_THROW_EXCEPTIONS);
That wouldn't break backwards-compatibility, but would
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 29 July 2017 at 15:16, Andrea Faulds wrote:
> Could we not simply make it a flag? e.g.
>
> $bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
> $baz = json_decode($bar, false, 512, JSON_THROW_EXCEPTIONS);
>
> That wouldn't break backwards-compatibility, but would still provide the
> desi
Hi everyone,
Andrea Faulds wrote:
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 can be
s
On Sat, Jul 29, 2017 at 10:08 AM, Andrea Faulds 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,
Hi Duncan,
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 can be
silenced by those that do
> 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 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 need
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
Am 29.07.2017 um 08:47 schrieb Thomas Hruska:
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 ad
Hi,
Lately there was a discovering about some files causing size growth of the
release tarballs
https://github.com/php/php-src/commit/469206c84e502e3e349655b802899d5e4d560f72
. Usually we strive to keep tarballs as small as possible and avoid
disproportional growth of the size. This case seems
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 28 July 2017 at 07:40, Andrew Nester wrote:
> Hello!
>
> the only way to add some custom classes and behavior is to approach this is
> by subclassing PDO and PDOStatement.
Please could you explicitly say when this is a problem, or what using
an interface allows?
I can imagine possible scen
24 matches
Mail list logo
