Re: [PHP-DEV] Re: [RFC] Random Extension 3.0

[Nikita Popov]

On Sun, Sep 5, 2021 at 7:40 PM Ben Ramsey  wrote:

> Go Kudo wrote on 9/4/21 23:00:
> > Indeed, it may be true that these suggestions should not be made all at
> > once. If necessary, I would like to propose to organize the RNG
> > implementation first.
> >
> > Do we still need an RFC in this case? I'm not sure I'm not fully
> understand
> > the criteria for an RFC. Does this internal API change count as a BC
> Break
> > that requires an RFC?
>
> Yes, since re-organizing the RNG implementation is a major language
> change that affects extensions and other downstream projects, this
> requires an RFC.
>
> >> Personally, I don't see the benefit of including this OOP API in the
> core.
> >
> > On the other hand, can you tell me why you thought it was unnecessary?
> > Was my example unrealistic?
>
> You also said, in reply to Dan Ackroyd:
>
> > Either way, I'll try to separate these suggestions if necessary, but if
> we
> > were to try to provide an OOP API without BC Break, what do you think
> would
> > be the ideal form?
>
> The OOP API appears to be a wrapper around the RNG functions. The only
> thing it gains by being in the core is widespread use, but it loses a
> lot of flexibility and maintainability, since the API will be tied to
> PHP release cycles.
>
> By doing this as an OOP wrapper in userland code, you're not restricting
> yourself to release only when PHP releases, and you can work with the
> community (e.g., the PHP-FIG) to develop interfaces that other projects
> might use so they can make use of their own RNGs, etc.
>

The OO API is not just a wrapper around the RNG functions -- it provides
new functionality that cannot be efficiently implemented in userland code.
This is for two reasons:

1. It provides independent randomness streams, which means it's not
possible to reuse existing functionality like mt_rand() for this purpose,
which only provides a single global random number stream. You would have to
reimplement the random number generator in userland. While this is
possible, it will generally not be efficient, because PHP does not have
native support for unsigned modular arithmetic, which is what random number
generators generally need.

2. It allows using functions like shuffle() and array_rand() with an
independent randomness stream. These functions cannot be efficiently
implemented in userland, because userland does not have random access to
arrays. Internals can generate a random number and use it to pick the key
at that position, which is O(1). Userland would have to call array_keys()
first to allow random access on keys, which is O(n).

Which is why I think this is a good addition to php-src. There's three good
reasons to include functionality in php-src (performance, ubiquity and FFI)
and this falls squarely into the first category. And now that we have
fibers and need to worry more about multiple independent execution streams,
we also need to worry about multiple independent randomness streams.

Regards,
Nikita

Re: [PHP-DEV] Adding a way to disable the stat cache

[Benjamin Eberlei]

On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan 
wrote:

> PS i've seen *HORRIBLE* fs performance for php-running-on-windows,
> where the same filesystem operations on the same files took like 5 seconds
> on linux-running-on-vmware-on-laptop-running-windows-10, versus several
> minutes for the same operation on the same laptop on windows 10 directly..
> for people looking for best-case-scenario for the stat cache, try looking
> at windows fs performance.. (if anyone even cares about that? i personally
> don't, i never run anything performance-sensitive-php code on Windows, just
> noticed horrible fs performance in the past)
>

The stat cache does not necessarily solve this issues though, only in very
limited cases where you work with the *same* file over and over again. The
stat cache only ever has exactly one entry, the *last* file that was
accessed. So if you work with many diferent files the stat cache does not
do what you would expect, to store the information of all these files. It
overwrites the cache with a new file entry when its not the same file as
currently stored.

>
> On Fri, 3 Sept 2021 at 22:22, Kevin Lyda  wrote:
>
> > On Fri, Sep 3, 2021 at 9:12 PM Christian Schneider
> >  wrote:
> > > I'm interested in the load put on a system with a high request count
> and
> > a typical application.
> > > Reducing system calls used to matter there as the kernel does not
> > multi-process the same way user land does.
> > >
> > > But then again, maybe I'm overly cautious :-)
> >
> > This PR allows people to do just that experiment.
> >
> > Kevin
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Matthew Brown]

> On Sep 6, 2021, at 11:29 AM, Nikita Popov  wrote:
> 

I think this would be a massive benefit to first-time PHP users one or two 
years from now.

I remember being confused by this terminology — I am sure bugs have been caused 
by people who assumed stdClass was a base class for all objects.

Best wishes,

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

[PHP-DEV] Re: Alias stdClass to DynamicObject?

[Björn Larsson via internals]

Den 2021-09-06 kl. 17:28, skrev Nikita Popov:

Hi internals,

In the thread for deprecation of dynamic properties, Rowan suggested that
we alias "stdClass" to "DynamicObject" in
https://externals.io/message/115800#115802. I wanted to split this
discussion off into a separate thread, as this can be decided independently.

The rationale for this is that "stdClass" is something of a misnomer: The
name makes it sound like this is a common base class, as used in a number
of other languages. However, PHP does not have a common base class. The
only way in which "stdClass" is "standard" is that it is the return type of
casting an array to (object).

The actual role of stdClass is to serve as a container for dynamic
properties, thus the suggested DynamicObject name.

What do people think about adding such an alias? Is this worthwhile?

Regards,
Nikita



Well, we have legacy code where stdClass is quite prevalent and the code
works just fine!

In case of deprecation of stdClass I would like to point out that the
benefit of replacing "new stdClass" with "new DynamicObject" in our
existing code is absolutely zero. However, using DynamicObject in new
code has a benefit since the intent is clearer.

I think one also should take into account how much is stdClass described
in documentation and books. Reason is that deprecation is not just about
how it affects code. I'm a bit of a book worm so I'll check up on how
the usage of stdClass is described in some PHP books.

If deprecation of stdClass is on the table I think it should target the
last 8.x or 9.0 zero release.

r//Björn L

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

Re: [PHP-DEV] Re: [RFC] Random Extension 3.0

[Go Kudo]

Nikita, Thanks for the clarification.
That's exactly what I intended to do.

> can you update the RFC with more information about this functionality?

I understand. Organize them and reconstruct the RFC text.

I've also created an RFC about moving RNG-related functions from
ext/standard to ext/random. I would appreciate it if you could check it out.

https://wiki.php.net/rfc/random_ext

Regards,
Go Kudo

2021年9月7日(火) 2:24 Ben Ramsey :

> Nikita Popov wrote on 9/6/21 03:06:
> > On Sun, Sep 5, 2021 at 7:40 PM Ben Ramsey  wrote:
> >
> >> Go Kudo wrote on 9/4/21 23:00:
> >>> Indeed, it may be true that these suggestions should not be made all at
> >>> once. If necessary, I would like to propose to organize the RNG
> >>> implementation first.
> >>>
> >>> Do we still need an RFC in this case? I'm not sure I'm not fully
> >> understand
> >>> the criteria for an RFC. Does this internal API change count as a BC
> >> Break
> >>> that requires an RFC?
> >>
> >> Yes, since re-organizing the RNG implementation is a major language
> >> change that affects extensions and other downstream projects, this
> >> requires an RFC.
> >>
>  Personally, I don't see the benefit of including this OOP API in the
> >> core.
> >>>
> >>> On the other hand, can you tell me why you thought it was unnecessary?
> >>> Was my example unrealistic?
> >>
> >> You also said, in reply to Dan Ackroyd:
> >>
> >>> Either way, I'll try to separate these suggestions if necessary, but if
> >> we
> >>> were to try to provide an OOP API without BC Break, what do you think
> >> would
> >>> be the ideal form?
> >>
> >> The OOP API appears to be a wrapper around the RNG functions. The only
> >> thing it gains by being in the core is widespread use, but it loses a
> >> lot of flexibility and maintainability, since the API will be tied to
> >> PHP release cycles.
> >>
> >> By doing this as an OOP wrapper in userland code, you're not restricting
> >> yourself to release only when PHP releases, and you can work with the
> >> community (e.g., the PHP-FIG) to develop interfaces that other projects
> >> might use so they can make use of their own RNGs, etc.
> >>
> >
> > The OO API is not just a wrapper around the RNG functions -- it provides
> > new functionality that cannot be efficiently implemented in userland
> code.
> > This is for two reasons:
> >
> > 1. It provides independent randomness streams, which means it's not
> > possible to reuse existing functionality like mt_rand() for this purpose,
> > which only provides a single global random number stream. You would have
> to
> > reimplement the random number generator in userland. While this is
> > possible, it will generally not be efficient, because PHP does not have
> > native support for unsigned modular arithmetic, which is what random
> number
> > generators generally need.
> >
> > 2. It allows using functions like shuffle() and array_rand() with an
> > independent randomness stream. These functions cannot be efficiently
> > implemented in userland, because userland does not have random access to
> > arrays. Internals can generate a random number and use it to pick the key
> > at that position, which is O(1). Userland would have to call array_keys()
> > first to allow random access on keys, which is O(n).
> >
> > Which is why I think this is a good addition to php-src. There's three
> good
> > reasons to include functionality in php-src (performance, ubiquity and
> FFI)
> > and this falls squarely into the first category. And now that we have
> > fibers and need to worry more about multiple independent execution
> streams,
> > we also need to worry about multiple independent randomness streams.
> >
> > Regards,
> > Nikita
> >
>
> Thanks for the clarification, Nikita.
>
> The RFC says, "The Random class is a utility class that provides
> functionality using random numbers." This led me to think it was a
> wrapper that did not introduce new functionality.
>
> I can't find any discussion in the RFC on the independent randomness
> streams provided by the OOP API. Go Kudo, can you update the RFC with
> more information about this functionality?
>
> Cheers,
> Ben
>
>

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Kamil Tekiela]

Hi Nikita,

I think this might be a good idea, but I would like to propose yet another
variant.
Replace stdClass with DynamicObject and keep stdClass as an alias. It can
be deprecated in 8.3.
If we only add an alias, I am afraid that it will not catch on quickly
enough. What I am proposing is that the cast to object will create
DynamicObject by default.

$arr = [1,2];
var_dump((object) $arr);
Output:
object(DynamicObject)#1 (2) {
  ["0"]=>
  int(1)
  ["1"]=>
  int(2)
}

It will break unit tests and it might break some code (e.g. `if ('stdClass'
=== $class)`), but it will help people understand what is the preferred
name going forward without deprecating it right now.

Regards,
Kamil

Re: [PHP-DEV] Re: [RFC] Random Extension 3.0

[Ben Ramsey]

Nikita Popov wrote on 9/6/21 03:06:
> On Sun, Sep 5, 2021 at 7:40 PM Ben Ramsey  wrote:
> 
>> Go Kudo wrote on 9/4/21 23:00:
>>> Indeed, it may be true that these suggestions should not be made all at
>>> once. If necessary, I would like to propose to organize the RNG
>>> implementation first.
>>>
>>> Do we still need an RFC in this case? I'm not sure I'm not fully
>> understand
>>> the criteria for an RFC. Does this internal API change count as a BC
>> Break
>>> that requires an RFC?
>>
>> Yes, since re-organizing the RNG implementation is a major language
>> change that affects extensions and other downstream projects, this
>> requires an RFC.
>>
 Personally, I don't see the benefit of including this OOP API in the
>> core.
>>>
>>> On the other hand, can you tell me why you thought it was unnecessary?
>>> Was my example unrealistic?
>>
>> You also said, in reply to Dan Ackroyd:
>>
>>> Either way, I'll try to separate these suggestions if necessary, but if
>> we
>>> were to try to provide an OOP API without BC Break, what do you think
>> would
>>> be the ideal form?
>>
>> The OOP API appears to be a wrapper around the RNG functions. The only
>> thing it gains by being in the core is widespread use, but it loses a
>> lot of flexibility and maintainability, since the API will be tied to
>> PHP release cycles.
>>
>> By doing this as an OOP wrapper in userland code, you're not restricting
>> yourself to release only when PHP releases, and you can work with the
>> community (e.g., the PHP-FIG) to develop interfaces that other projects
>> might use so they can make use of their own RNGs, etc.
>>
> 
> The OO API is not just a wrapper around the RNG functions -- it provides
> new functionality that cannot be efficiently implemented in userland code.
> This is for two reasons:
> 
> 1. It provides independent randomness streams, which means it's not
> possible to reuse existing functionality like mt_rand() for this purpose,
> which only provides a single global random number stream. You would have to
> reimplement the random number generator in userland. While this is
> possible, it will generally not be efficient, because PHP does not have
> native support for unsigned modular arithmetic, which is what random number
> generators generally need.
> 
> 2. It allows using functions like shuffle() and array_rand() with an
> independent randomness stream. These functions cannot be efficiently
> implemented in userland, because userland does not have random access to
> arrays. Internals can generate a random number and use it to pick the key
> at that position, which is O(1). Userland would have to call array_keys()
> first to allow random access on keys, which is O(n).
> 
> Which is why I think this is a good addition to php-src. There's three good
> reasons to include functionality in php-src (performance, ubiquity and FFI)
> and this falls squarely into the first category. And now that we have
> fibers and need to worry more about multiple independent execution streams,
> we also need to worry about multiple independent randomness streams.
> 
> Regards,
> Nikita
> 

Thanks for the clarification, Nikita.

The RFC says, "The Random class is a utility class that provides
functionality using random numbers." This led me to think it was a
wrapper that did not introduce new functionality.

I can't find any discussion in the RFC on the independent randomness
streams provided by the OOP API. Go Kudo, can you update the RFC with
more information about this functionality?

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Björn Larsson via internals]

Den 2021-09-06 kl. 18:22, skrev Christian Schneider:

Am 06.09.2021 um 18:08 schrieb Benjamin Morel :

Yes, please! A future where dynamic properties are only allowed on
DynamicObject is bright.


I have nothing against a DynamicObject alias for people who like to be more 
explicit in their code...



Totally agree here!


I would even deprecate the stdClass alias straight away, so that the whole
thing can be gone in PHP 9.


... but I'd prefer retaining a backward compatible version for library code, at 
least for a while and preferably without warnings :-)

- Chris


Couldn't agree more on the statement "without warnings"!

I mean if one have code that is in production, is running perfect and
one wants to upgrade to the newest and fanciest PHP version and the
logs are flooded with warnings for a deprecation with zero impact on
functionality. What do one do? Maybe just turn of the warnings for
that code section / library ;-)

r//Björn L

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

[PHP-DEV] [RFC] Move RNG functions ext/random

[Go Kudo]

Hi internals.

As a result of the exchange in the following thread, it seems appropriate
to separate the proposals.

In line with this, we have created a proposal to first clean up the
existing RNG-related functionality and move it from ext/standard to
ext/random.

https://wiki.php.net/rfc/random_ext

Hopefully this will get a good response.

Regards,
Go Kudo

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Aran Reeks]

Creating a new DynamicObject class which is the preferred alias for
stdClass sounds logical but I too share the consern around making it the
default anytime soon. Too much code depends on an expected type of stdClass
presently which would likely make future upgrades more difficult for no
functional gain, beyond some added clarify.

With functions such as json_decode() still returning stdClass by default,
this is the main bug bare I can forsee where we commonly strict type
passing the decoded value throuh to another method or type. Would be nice
if in the future you could specify a class to populate instead of stdClass
- just a thought.

I too share the same view on deprecation notices being enfored and although
this would probably warrent its own thread, perhaps there benefit in
resolving this in itself under another RFC where a new php.ini directive,
or method call could be used to silence certain specified deprecation
warnings for those that are aware and understand the changes required in
the future so can knowingly make a decision to mute them.

On Mon, 6 Sep 2021, 18:50 Björn Larsson via internals, <
internals@lists.php.net> wrote:

> Den 2021-09-06 kl. 18:22, skrev Christian Schneider:
> > Am 06.09.2021 um 18:08 schrieb Benjamin Morel  >:
> >> Yes, please! A future where dynamic properties are only allowed on
> >> DynamicObject is bright.
> >
> > I have nothing against a DynamicObject alias for people who like to be
> more explicit in their code...
> >
>
> Totally agree here!
>
> >> I would even deprecate the stdClass alias straight away, so that the
> whole
> >> thing can be gone in PHP 9.
> >
> > ... but I'd prefer retaining a backward compatible version for library
> code, at least for a while and preferably without warnings :-)
> >
> > - Chris
> >
> Couldn't agree more on the statement "without warnings"!
>
> I mean if one have code that is in production, is running perfect and
> one wants to upgrade to the newest and fanciest PHP version and the
> logs are flooded with warnings for a deprecation with zero impact on
> functionality. What do one do? Maybe just turn of the warnings for
> that code section / library ;-)
>
> r//Björn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Adding a way to disable the stat cache

[Pierre Joye]

On Mon, Sep 6, 2021, 6:14 PM Benjamin Eberlei  wrote:

> On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan 
> wrote:
>
>
> The stat cache does not necessarily solve this issues though, only in very
> limited cases where you work with the *same* file over and over again. The
> stat cache only ever has exactly one entry, the *last* file that was
> accessed. So if you work with many diferent files the stat cache does not
> do what you would expect, to store the information of all these files. It
> overwrites the cache with a new file entry when its not the same file as
> currently stored.


that is what happened in TS mode. For every part of a path, every single
time a path is used (like source files in a common root path). I did not
check it lately but I suppose it still does it. Luckily it should not be an
issue anymore as most should be using nts as well and the opcache, maybe
even wincache too which implements a smart cache with events (on change).

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christoph M. Becker]

On 06.09.2021 at 14:00, Pierre Joye wrote:

> On Mon, Sep 6, 2021, 6:14 PM Benjamin Eberlei  wrote:
>
>> On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan 
>> wrote:
>>
>> The stat cache does not necessarily solve this issues though, only in very
>> limited cases where you work with the *same* file over and over again. The
>> stat cache only ever has exactly one entry, the *last* file that was
>> accessed. So if you work with many diferent files the stat cache does not
>> do what you would expect, to store the information of all these files. It
>> overwrites the cache with a new file entry when its not the same file as
>> currently stored.
>
> that is what happened in TS mode. For every part of a path, every single
> time a path is used (like source files in a common root path). I did not
> check it lately but I suppose it still does it.

This is the realpath cache, though.

> Luckily it should not be an
> issue anymore as most should be using nts as well and the opcache, maybe
> even wincache too which implements a smart cache with events (on change).

FWIW, WinCache has been discontinued[1].

[1] 

Christoph

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Pierre Joye]

On Mon, Sep 6, 2021, 10:50 PM Christian Schneider 
wrote:

> Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> > Also as someone mentioned here afterwards, instead of removing it
> > straight away, I would go with the flag first, less risky :)
>
> Out of curiosity: Do you think disabling the stat cache could be harmful?
>

only for performance on windows TS. I think still too much use apache with
mod php I think.


If no, why make it an option?
> If yes, should we be allowing it?
>

yes, off by default first?


best
Pierre

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 05.09.2021 um 13:30 schrieb Kevin Lyda :
> Any more thoughts on https://github.com/php/php-src/pull/5894 ?
> I've resolved the merge conflict. It would be nice to close out this bug.

For the record in case it was missed:
If we deem the stat cache to be useless I'd rather remove it completely to 
avoid further WTFs based on a hoster's configuration.

- Chris

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Pierre Joye]

On Mon, Sep 6, 2021 at 7:05 PM Christoph M. Becker  wrote:
>
> On 06.09.2021 at 14:00, Pierre Joye wrote:
>
> > On Mon, Sep 6, 2021, 6:14 PM Benjamin Eberlei  wrote:
> >
> >> On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan 
> >> wrote:
> >>
> >> The stat cache does not necessarily solve this issues though, only in very
> >> limited cases where you work with the *same* file over and over again. The
> >> stat cache only ever has exactly one entry, the *last* file that was
> >> accessed. So if you work with many diferent files the stat cache does not
> >> do what you would expect, to store the information of all these files. It
> >> overwrites the cache with a new file entry when its not the same file as
> >> currently stored.
> >
> > that is what happened in TS mode. For every part of a path, every single
> > time a path is used (like source files in a common root path). I did not
> > check it lately but I suppose it still does it.
>
> This is the realpath cache, though.

realpath(path, 1) does not do stat anymore? I mean with
virtual_file_ex and co? Not so important, too long since I touched
this :)

Also as someone mentioned here afterwards, instead of removing it
straight away, I would go with the flag first, less risky :)

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

[PHP-DEV] Alias stdClass to DynamicObject?

[Nikita Popov]

Hi internals,

In the thread for deprecation of dynamic properties, Rowan suggested that
we alias "stdClass" to "DynamicObject" in
https://externals.io/message/115800#115802. I wanted to split this
discussion off into a separate thread, as this can be decided independently.

The rationale for this is that "stdClass" is something of a misnomer: The
name makes it sound like this is a common base class, as used in a number
of other languages. However, PHP does not have a common base class. The
only way in which "stdClass" is "standard" is that it is the return type of
casting an array to (object).

The actual role of stdClass is to serve as a container for dynamic
properties, thus the suggested DynamicObject name.

What do people think about adding such an alias? Is this worthwhile?

Regards,
Nikita

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Christian Schneider]

Am 06.09.2021 um 18:08 schrieb Benjamin Morel :
> Yes, please! A future where dynamic properties are only allowed on
> DynamicObject is bright.

I have nothing against a DynamicObject alias for people who like to be more 
explicit in their code...

> I would even deprecate the stdClass alias straight away, so that the whole
> thing can be gone in PHP 9.

... but I'd prefer retaining a backward compatible version for library code, at 
least for a while and preferably without warnings :-)

- Chris

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

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Benjamin Morel]

Hi Nikita, Rowan,

In the thread for deprecation of dynamic properties, Rowan suggested that
> we alias "stdClass" to "DynamicObject" in
> https://externals.io/message/115800#115802. I wanted to split this
> discussion off into a separate thread, as this can be decided
> independently.
>
> The rationale for this is that "stdClass" is something of a misnomer: The
> name makes it sound like this is a common base class, as used in a number
> of other languages. However, PHP does not have a common base class. The
> only way in which "stdClass" is "standard" is that it is the return type of
> casting an array to (object).
>
> The actual role of stdClass is to serve as a container for dynamic
> properties, thus the suggested DynamicObject name.
>
> What do people think about adding such an alias? Is this worthwhile?


Yes, please! A future where dynamic properties are only allowed on
DynamicObject is bright.

I would even deprecate the stdClass alias straight away, so that the whole
thing can be gone in PHP 9.

Kind regards,
Benjamin

>

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> Also as someone mentioned here afterwards, instead of removing it
> straight away, I would go with the flag first, less risky :)

Out of curiosity: Do you think disabling the stat cache could be harmful?
If no, why make it an option?
If yes, should we be allowing it?

Follow-up question: What would be the default?
Cache off which might be harmful to some (assumedly bigger) sites?
Cache on which won't fix the bug reports?

If you put the burden on the bigger PHP users by making it default to off 
you're assuming they have more rigorous update procedures, I guess. Probably 
true, just make sure that it is mentioned prominently enough in UPGRADING.

Ok, I've said my piece :-)
- Chris

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

[PHP-DEV] Re: Alias stdClass to DynamicObject?

[Rowan Tommins]

On 06/09/2021 18:36, Björn Larsson wrote:

In case of deprecation of stdClass I would like to point out that the
benefit of replacing "new stdClass" with "new DynamicObject" in our
existing code is absolutely zero. However, using DynamicObject in new
code has a benefit since the intent is clearer. 



Just to mildly challenge this: Why is the intent of old code any less 
important? Do you never hire junior developers, or those cross-training 
from other languages, who have to maintain that code? Do you never have 
days where your brain is just a bit fuzzy, and every extra meaning you 
have to think about is one less line of code you'll get written?


But yes, for experienced PHP developers, the name is not that big a 
deal. Indeed, a lot of PHP developers probably never even see it. It's 
one of those little "paper cuts", where if we can make the fix not too 
painful (including deprecation messages not being too annoying), it will 
pay off in the long run.


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] [RFC] Move RNG functions ext/random

[Pierre Joye]

Hi Go,

Awesome, excellent work and will make the whole thing easier :)

+1 already!

best,

On Tue, Sep 7, 2021 at 3:29 AM Go Kudo  wrote:
>
> Hi internals.
>
> As a result of the exchange in the following thread, it seems appropriate
> to separate the proposals.
>
> In line with this, we have created a proposal to first clean up the
> existing RNG-related functionality and move it from ext/standard to
> ext/random.
>
> https://wiki.php.net/rfc/random_ext
>
> Hopefully this will get a good response.
>
> Regards,
> Go Kudo



-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Hossein Baghayi]

On Tue, 7 Sept 2021 at 01:12, Aran Reeks  wrote:

> ... Too much code depends on an expected type of stdClass
> presently which would likely make future upgrades more difficult for no
> functional gain, beyond some added clarify.


What if we had the DynamicObject as a subclass of stdClass?
It would reduce the impact.

I don't know if aliasing works the same as with subclassing (regarding type
checking).