Re: [PHP-DEV] Alias stdClass to DynamicObject?
On Mon, Sep 6, 2021 at 9:29 AM Nikita Popov wrote: > > 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 If the alias goes to vote as the name DynamicObject, then I will likely abstain. I don't care. If it goes to vote under some other name, perhaps "map", or "dict", then I would likely oppose it. I would like to keep those names available for more useful features. There are multiple feature that would like these names: 1. Hacklang-style dict, which is a value-based dictionary type. Importantly, this is copy-on-write like an array; it does not have object semantics. 2. In the event we ever add generics, it would be nice to have these names available for interfaces. I don't think an alias and replacement name for stdClass is important enough to use these names. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Option for array_column() to preserve keys.
Hello internals, The function array_column() would be much more useful if there was an option to preserve the original array keys. I can create an RFC, but I think it is better to first discuss the options. This is requested in different places on the web, e.g. https://stackoverflow.com/questions/27204590/php-array-column-how-to-keep-the-keys/39298759 A workaround is proposed here and elsewhere, using array_keys() and array_combine() to restore the keys. However, this workaround not only adds complexity, but it breaks down if some items don't have the value key. See https://3v4l.org/im2gZ. A more robust workaround would be array_map(), but this is more complex and probably slower than array_column(), for the given purpose. Some links for your convenience: The function was introduced in this RFC, https://wiki.php.net/rfc/array_column It is now documented here, https://www.php.net/manual/en/function.array-column.php Some ideas how this could be fixed: 1. Allow a magic value (e.g. TRUE) for the $index_key parameter, that would cause the assoc behavior. To fully avoid BC break, this must be a value that previously was completely forbidden. The value TRUE is currently only forbidden with strict_types=1. A value of e.g. new \stdClass is fully forbidden, but would be weird. A constant could be introduced, but this would not prevent the BC concern. 2. Make the function preserve keys if $index_key === NULL. This would be a full BC break. 3. Add an additional parameter with a boolean option or with integer flags. This would be weird, because it would make the $index_key parameter useless. 4. Add a new function. Personally I would prefer option 1, with value TRUE (I can't think of something better). If I could change history, I would prefer option 2. The current behavior could still be achieved with array_values(array_column(..)). Regards, Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Alias stdClass to DynamicObject?
Hi Marc, The name seems to be ok IMHO. Even though it is a class, the main use case is to denote an object that was created dynamically rather than through an instantiation of a class. And I know that a lot of usage comes from people directly creating new instances of stdClass but if you do that then you can use proper classes also (with Nikita's proposal to deprecate dynamic properties one would have to use a class with defined properties to do the same). It's not unheard that a class has "object" in the name. e.g. https://docs.oracle.com/javaee/7/api/javax/json/JsonObject.html or https://docs.microsoft.com/en-us/dotnet/api/system.json.jsonobject?view=dotnet-plat-ext-5.0 The name DynamicObject is also used in other languages. https://docs.microsoft.com/en-us/dotnet/api/system.dynamic.dynamicobject?view=net-5.0 The word "Dynamic" semantically explains the purpose of the instance of such class: it has no fixed structure. We could call it Map or Dictionary, which would also be fitting, but in doing so we are opening up the scope of this RFC. How much more functionality does PHP need? What would be the goal of it? PHP has tons of functions for working with arrays. If we introduce another type like Map then it would be expected that a set of methods be added to it. This sounds similar to scalar objects. And while it would be nice to have such kind of functionality in PHP, it would also be a lot of work to implement it. If we already have associative arrays, do we really need another structure to do the same thing? I think it would be prudent to first understand why people are using stdClass in the first place. From my experience, most of the time people who work with stdClass don't expect it to have any methods. It's just a container for data just like an array, but with a different syntax. It's not much more different than an anonymous class. The goal of Nikita's proposal is to retain the functionality of dynamically assigning properties to an object after deprecating dynamic properties on all other objects. The new class DynamicObject would be a special type of class that would retain this functionality. Thus, the name fits perfectly. A DynamicObject is a class whose properties can be created dynamically. Regards, Kamil
Re: [PHP-DEV] Alias stdClass to DynamicObject?
On 06.09.21 17:28, Nikita Popov wrote: 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? I do like the idea very much as "stdClass" is most confusion and also wrong. The name "DynamicObject" is much better but I'm not sure if this is a good name either. * It's a class -> Why do we suffix it with "Object"? * Yes it's about dynamic properties - but is this the user goal to have dynamic properties or is it an implementation detail to get something else (map/dict)? Wouldn't it be better to name it for what purpose it's being used (map/dict/ordered dict/...) instead of how this is done? And if we want to go that route we could also add common functionalities to it like getting list of keys/values converting to array iterating etc. it's already possible right know by casting to array but it would be more logically. Yes we have assoc arrays in PHP to serve the purpose but this also has it's downsides as there is no type for it and the issue of converting an empty array from/to JSON (is it a list or a map?). The big difference, of course, is the by-ref vs. by-value. Hope that's not stupid questions? Greetings, Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Alias stdClass to DynamicObject?
On Tue, Sep 7, 2021, at 4:22 AM, Nikita Popov wrote:
> On Mon, Sep 6, 2021 at 6:50 PM Kamil Tekiela wrote:
>
> > 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.
> >
>
> My only apprehension with making stdClass rather than DynamicObject the
> alias is the widespread impact this will have on extension testing code.
> https://github.com/php/php-src/pull/7475 shows the approximate impact on
> php-src. We need to update references to stdClass in var_dump() output in
> more than 300 tests. We can do this easily, but it will be an inconvenience
> for 3rd party extension tests that need to deal with more than one PHP
> version.
>
> Apart from that I agree that making DynamicObject the actual name and
> stdClass the alias would be better.
>
> Regards,
> Nikita
Adding the alias, I'm fully on board with.
Removing stdClass any time before PHP 10, I'm not on board with. The user
space breakage potential is too large to even be thinking about that at this
point.
Flipping the alias around... again, I'm very concerned about the BC breakage.
Apparently `readonly` caused problems for Wordpress, which is doubleplusungood.
I would assume that we can't safely change which is the real name until proven
otherwise, and based on Nikita's comments about PHP's own tests, I'd say it's
definitely not proven otherwise.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] $this return type
Am 07.09.2021 um 12:28 schrieb Nikita Popov: I have some reservations about this (which basically come down to $this not being a proper "type", so should it be in the type system?) but I can see the practical usefulness, so I think it's worth discussing this. I am not conviced that there is enough value in this to introduce syntax for it, but if at all, then please not "$this" as the name for a type. Off the top of my head, I think that "same" could make sense. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] $this return type
On 07.09.2021 at 15:02, Andreas Heigl wrote: > On 07.09.21 12:28, Nikita Popov wrote: > >> I'd like to pick up a loose thread from the future scope of the >> https://wiki.php.net/rfc/static_return_type RFC, the $this return type >> for >> fluent APIs: >> >> https://wiki.php.net/rfc/this_return_type >> >> I have some reservations about this (which basically come down to >> $this not >> being a proper "type", so should it be in the type system?) but I can see >> the practical usefulness, so I think it's worth discussing this. > > If we allow a $this (let's keep the actual naming out for the moment) as > a returntype to clarify that it has to be the same instance that is > returned, I would also either expect that the returntype 'self' does > explicitly *not* allow the same instance to be returned. As that would > be a huge BC break I would on the other hand also think that we should > implement a returntype "!$this" to explicitly state that the contract > here returns *not* the current instance but a new one. That way a lot > of immutable contracts could be made more clear. > > What'S your or others idea regarding that? In my opinion, we should not muddy the waters here. $this is not a type. Instead we should consider to head for a more general solution, namely suporting post-conditions, i.e. assertions which are part of the function/method signature. But that would certainly be the topic of another RFC. Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] $this return type
Hey Nikita On 07.09.21 12:28, Nikita Popov wrote: Hi internals, I'd like to pick up a loose thread from the future scope of the https://wiki.php.net/rfc/static_return_type RFC, the $this return type for fluent APIs: https://wiki.php.net/rfc/this_return_type I have some reservations about this (which basically come down to $this not being a proper "type", so should it be in the type system?) but I can see the practical usefulness, so I think it's worth discussing this. Regards, Nikita If we allow a $this (let's keep the actual naming out for the moment) as a returntype to clarify that it has to be the same instance that is returned, I would also either expect that the returntype 'self' does explicitly *not* allow the same instance to be returned. As that would be a huge BC break I would on the other hand also think that we should implement a returntype "!$this" to explicitly state that the contract here returns *not* the current instance but a new one. That way a lot of immutable contracts could be made more clear. What'S your or others idea regarding that? Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] $this return type
Hi Nikita, wt., 7 wrz 2021 o 12:29 Nikita Popov napisał(a): > Hi internals, > > I'd like to pick up a loose thread from the future scope of the > https://wiki.php.net/rfc/static_return_type RFC, the $this return type for > fluent APIs: > > https://wiki.php.net/rfc/this_return_type > > I have some reservations about this (which basically come down to $this not > being a proper "type", so should it be in the type system?) but I can see > the practical usefulness, so I think it's worth discussing this. If the aim of $this return type is to force and check the return $this why would we still need/require return statement to be obligatory? Does that make sense to assume at the end of function flow the return $this; statement to be present by default if the return type is not an union etc.? Cheers, -- Michał Marcin Brzuchalski
Re: [PHP-DEV] Adding a way to disable the stat cache
Hi, On Tue, Sep 7, 2021, 5:49 PM Kamil Tekiela wrote: > It's WSL2 > uname -r > 5.4.72-microsoft-standard-WSL2 > no need to test on wsl2, that's a dockerized linux. best, Pierre >
Re: [PHP-DEV] Adding a way to disable the stat cache
It's WSL2 uname -r 5.4.72-microsoft-standard-WSL2
Re: [PHP-DEV] Adding a way to disable the stat cache
WSL1 or WSL2? afaik they have significant performance differences, and we should only consider WSL2 as WSL1 is being deprecated afaik On Tue, 7 Sept 2021 at 12:31, Kamil Tekiela wrote: > > It would be great if someone on > Windows and macos could repeat this experiment > > I ran this on Windows and I got the following results: > Native Windows build: > > Without cache > real0m31.170s > user0m0.000s > sys 0m0.000s > > With cache > real0m0.694s > user0m0.000s > sys 0m0.000s > > Ubuntu WSL: > > Without cache > real3m8.695s > user0m7.009s > sys 0m18.819s > > With cache > real0m0.707s > user0m0.562s > sys 0m0.010s > > I am not sure how to interpret it. I doubt that any system would actually > perform 1 million operations on the same file, but I can definitely see a > noticeable difference. >
Re: [PHP-DEV] Adding a way to disable the stat cache
> It would be great if someone on Windows and macos could repeat this experiment I ran this on Windows and I got the following results: Native Windows build: Without cache real0m31.170s user0m0.000s sys 0m0.000s With cache real0m0.694s user0m0.000s sys 0m0.000s Ubuntu WSL: Without cache real3m8.695s user0m7.009s sys 0m18.819s With cache real0m0.707s user0m0.562s sys 0m0.010s I am not sure how to interpret it. I doubt that any system would actually perform 1 million operations on the same file, but I can definitely see a noticeable difference.
[PHP-DEV] [RFC] $this return type
Hi internals, I'd like to pick up a loose thread from the future scope of the https://wiki.php.net/rfc/static_return_type RFC, the $this return type for fluent APIs: https://wiki.php.net/rfc/this_return_type I have some reservations about this (which basically come down to $this not being a proper "type", so should it be in the type system?) but I can see the practical usefulness, so I think it's worth discussing this. Regards, Nikita
Re: [PHP-DEV] [RFC] [VOTE] is_literal
On Mon, 19 Jul 2021 at 19:59, Craig Francis wrote: > On Mon, 5 Jul 2021 at 19:14, Craig Francis > wrote: > >> I have opened voting on https://wiki.php.net/rfc/is_literal for the >> is-literal function. >> > > This RFC has been rejected; with 10 votes in favour, and 23 against. > [...] > And thank you to Matthew Brown for adding the 'literal-string' type to > Psalm: > https://github.com/vimeo/psalm/releases/tag/4.8.0 > FYI: The 'literal-string' type has now been added to PHPStan, thanks to Ondřej Mirtes: https://github.com/phpstan/phpstan/releases/tag/0.12.97 Obviously I'd still like libraries to be able to protect everyone from introducing Injection Vulnerabilities (as the majority of programmers don't use static analysis), but that's for another day. Craig
Re: [PHP-DEV] Alias stdClass to DynamicObject?
On Mon, Sep 6, 2021 at 6:50 PM Kamil Tekiela wrote:
> 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.
>
My only apprehension with making stdClass rather than DynamicObject the
alias is the widespread impact this will have on extension testing code.
https://github.com/php/php-src/pull/7475 shows the approximate impact on
php-src. We need to update references to stdClass in var_dump() output in
more than 300 tests. We can do this easily, but it will be an inconvenience
for 3rd party extension tests that need to deal with more than one PHP
version.
Apart from that I agree that making DynamicObject the actual name and
stdClass the alias would be better.
Regards,
Nikita
Re: [PHP-DEV] Adding a way to disable the stat cache
On Fri, Sep 3, 2021 at 7:10 PM Kevin Lyda wrote:
> [sent a second time, now to the list, sorry]
>
> On Fri, Sep 3, 2021 at 3:53 PM Christian Schneider
> wrote:
> > How can you say "it never was a problem" if we never had to live without
> stat cache?
> > Can you back up that claim with numbers? There are some of us who run
> high-volume websites where system load increase could be a problem.
>
> Using this bash script:
>
> #!/bin/bash
> echo "Without cache"
> time ./sapi/cli/php -d enable_stat_cache=3DFalse "$@"
> echo "With cache"
> time ./sapi/cli/php "$@"
>
> To run this php script:
>
> $iterations =3D 100;
> function all_the_stats($filename) {
> @lstat($filename);
> @stat($filename);
> }
> while ($iterations--) {
> all_the_stats(__FILE__);
> }
>
> I see this output:
>
> Without cache
>
> real 0m7.326s
> user 0m5.877s
> sys 0m1.448s
> With cache
>
> real 0m5.010s
> user 0m5.009s
> sys 0m0.000s
>
> So that's 2 seconds slower to do 2 million uncached stat calls vs
> cached with a 100% cache hit rate (minus the first stat/lstat calls).
>
> Technically, yes, it's slower, but I'd suggest that making 2 million stat
> calls to a single file is a bad idea. And remember, the cache holds *one*
> file. If you stat a second file it's a cache miss.
>
These numbers look pretty good to me. It would be great if someone on
Windows and macos could repeat this experiment, so we have an idea of how
other platforms fare in this worst-case scenario.
Regards,
Nikita
Re: [PHP-DEV] [RFC] Random Extension 3.0
On Thu, Sep 2, 2021 at 5:10 PM Go Kudo wrote: > Hi Internals. > > Expanded from the previous RFC and changed it to an RFC that organizes the > whole PHP random number generator. Also, the target version has been > changed to 8.2. > > https://wiki.php.net/rfc/rng_extension > https://github.com/php/php-src/pull/7453 > > Hopefully you will get some good responses. > This RFC currently tries to keep some semblance of compatibility with the existing mt_rand() algorithm by retaining the same implementation for mapping the raw random number stream into a range. However, the algorithm we use for that is not exactly state of the art and requires two full-width divisions at minimum. There are more efficient scaling algorithms based on fixed-point multiplication, which are "nearly divisionless" ( https://arxiv.org/pdf/1805.10941.pdf). The variant at https://github.com/apple/swift/pull/39143 is entirely divisionless. Doing this would improve performance (though I'm not sure by how much -- maybe once we add up our call overhead, it isn't important anymore?) but it would provide a different sequence than mt_rand(). Something we might want to consider. Regards, Nikita
Re: [PHP-DEV] [RFC] Random Extension 3.0
On Sat, Sep 4, 2021 at 10:57 PM Marc wrote: > > On 9/2/21 5:10 PM, Go Kudo wrote: > > Hi Internals. > > > > Expanded from the previous RFC and changed it to an RFC that organizes > the > > whole PHP random number generator. Also, the target version has been > > changed to 8.2. > > > > https://wiki.php.net/rfc/rng_extension > > https://github.com/php/php-src/pull/7453 > > > > Hopefully you will get some good responses. > > For me (user land developer with no voting power) your RFC looks pretty :) > > Beside the abstract vs interface question I have some other notes: > > On the one hand you define "getBytes()" which returns a string and on > the other hand you define "shuffleString()" - is the first one a binary > string and the other a charset dependent string? I guess here > "shuffleString()" works on byte level and so it should be "shuffleBytes()". > > Why are there no default values for min/max on "getInt()" - It seems > unnecessary to me to pass min/max arguments if you are just interested > in a random integer or passing max as well if you are interested in a > positive integer only. > Because the default range is not obvious. For example mt_rand() without min/max will actually return only non-negative integers, so someone might expect $random->getInt() to do the same, even though it makes very little sense. $random->getInt($n) could be interpreted either as a number in $n..PHP_INT_MAX (if we just see it as leaving $max at the default value), or 0..$n-1 (a very common convention for single-argument random integer functions). Requiring both arguments makes the meaning unambiguous. Regards, Nikita
