Re: [PHP-DEV] Typed array properties V2
> I have a PR that reduces the [minimum capacity of a packed array from 8] to > 2, noticeably decreasing memory - > the largest blockers were getting a realistic idea of whether commonly used > applications > would see a decrease or increase in runtime, and needing code review. Sorry, I forgot to include the link to it, it was https://github.com/php/php-src/pull/4783 - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed array properties V2
> I'm unsure of exactly how this might work so defer to an Internals export,
> but having previously read @Nikita Popov 's great
> post on PHP's arrays, I did wonder if by knowing the data type within an
> array and that it'd conform to a strict structure, could the array itself
> be stored in an alternative way in C? Perhaps a more memory efficient way,
> or one that's faster to iterate over rather than just a hash table?
> Link to this article for reference:
> https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html
A significant improvement that could be made to memory efficiency is to reduce
the minimum array size for *dynamically* created arrays.
Currently, it's always 8 and must be a power of 2, even if there's only one
element or the array is packed (i.e. a list without gaps)
- Array constants cached in opcache already have this optimization.
I have a PR that reduces the minimum size to 2 - the largest blockers were
getting a realistic idea of whether commonly used applications
would see a decrease or increase in runtime, and needing code review.
("I'd want to know how this would be benchmarked before adding more changes, in
case additional optimizations somehow turn out to be a performance regression.")
> For example, Phan's memory usage for self-analysis (./phan
> --print-memory-usage-summary)
> went from 444MB/576MB to 387MB/475MB (end memory/max memory) with this patch.
> (This is a static analyzer for PHP which heavily uses small arrays)
> I did wonder if by knowing the data type within an
> array and that it'd conform to a strict structure
> could the array itself be stored in an alternative way in C?
It might theoretically be possible to optimize the memory of an `int[]` (64
bits per element) without references or gaps in elements.
If a reference in an element got added, or it stopped being a packed array
without gaps (i.e. a list),
then such an implementation would use an unoptimized version that also enforces
the type constraint
(128 bits per list element with zvals).
It would probably require changing a lot of APIs and macros, and I'd have no
idea how to implement it.
I think JavaScript engines do something similar by having specializations for
JS arrays of integers,
arrays of floats, arrays of small (e.g. 16-bit) integers, etc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed array properties V2
Hi Mike,
Thanks for your support, and yes, you're correct, I did mean to structure
the type prior to the [].
I'm unsure of exactly how this might work so defer to an Internals export,
but having previously read @Nikita Popov 's great
post on PHP's arrays, I did wonder if by knowing the data type within an
array and that it'd conform to a strict structure, could the array itself
be stored in an alternative way in C? Perhaps a more memory efficient way,
or one that's faster to iterate over rather than just a hash table?
Link to this article for reference:
https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html
Cheers,
Aran
On Fri, 17 Jan 2020 at 19:17, Mike Schinkel wrote:
>
> > On Jan 17, 2020, at 2:50 AM, Aran Reeks wrote:
> > That said, there's a common use case that keeps me going back to them
> which
> > I think would be a good thing for PHP to try and solve as a language
> > feature - better typing of arrays to type their properties.
>
> I for one would be a big +1 for this, with caveats.
>
> > IDEs like PHPStorm handle this structure already hence sticking to that
> as
> > a starting point...
> >
> > @returns []int
>
> As previously noted, I assume you meant int[]?
>
>
>
> Having the ability to type array elements would cover ~90% of the cases
> where I cannot properly type parameters or return values in PHP 7.4.
>
> The caveat is that it would seem that to check dynamically would be an
> expensive proposition such as when an array that was not typed is passed to
> or returned from a function or assigned to a variable of a declared type,
> e.g.
>
> function foo( $myarray ): Foo[] {
> return $myarray; // This would need to be dynamically checked, I
> think?
> }
>
> Of course we could limit this type of typing to only arrays that are
> already know to be typed, meaning this would always fail:
>
> function bar( Foo[] $myarray ) {
> // Do whatever
> }
> function baz( $myarray ) {
> bar( $myarray ); // Fails here because $myarray not known to be
> Foo[] even when it is
> }
> baz( [ new Foo() ] );
>
> Alternately we could have a global option that would do type checking or
> not for these type hints, so they could be dynamically checked for all code
> prior to production code, where checking could be turned off.
>
> Another option could be if the number of array elements is small (<100?)
> it could check, but otherwise not check, but this feels all kind of
> different types of wrong.
>
>
>
> My vote, if I had one, would be to add type new typing for array elements,
> but also add a type checking global option that can be in one of 3 states:
>
> 1. Static checks only,
> 2. Dynamic checks only, or
> 3. No checking of array elements.
>
> #jmtcw
>
> -Mike
> P.S. Or maybe there is an inexpensive way to keep track of the types of
> the entire array on element assignment?
> P.P.S. Can someone please explain and give an example of how generics
> would make this need moot? I do not get why that would be the case...
>
>
Re: [PHP-DEV] Typed array properties V2
> On Jan 17, 2020, at 2:50 AM, Aran Reeks wrote:
> That said, there's a common use case that keeps me going back to them which
> I think would be a good thing for PHP to try and solve as a language
> feature - better typing of arrays to type their properties.
I for one would be a big +1 for this, with caveats.
> IDEs like PHPStorm handle this structure already hence sticking to that as
> a starting point...
>
> @returns []int
As previously noted, I assume you meant int[]?
Having the ability to type array elements would cover ~90% of the cases where I
cannot properly type parameters or return values in PHP 7.4.
The caveat is that it would seem that to check dynamically would be an
expensive proposition such as when an array that was not typed is passed to or
returned from a function or assigned to a variable of a declared type, e.g.
function foo( $myarray ): Foo[] {
return $myarray; // This would need to be dynamically checked, I think?
}
Of course we could limit this type of typing to only arrays that are already
know to be typed, meaning this would always fail:
function bar( Foo[] $myarray ) {
// Do whatever
}
function baz( $myarray ) {
bar( $myarray ); // Fails here because $myarray not known to be Foo[]
even when it is
}
baz( [ new Foo() ] );
Alternately we could have a global option that would do type checking or not
for these type hints, so they could be dynamically checked for all code prior
to production code, where checking could be turned off.
Another option could be if the number of array elements is small (<100?) it
could check, but otherwise not check, but this feels all kind of different
types of wrong.
My vote, if I had one, would be to add type new typing for array elements, but
also add a type checking global option that can be in one of 3 states:
1. Static checks only,
2. Dynamic checks only, or
3. No checking of array elements.
#jmtcw
-Mike
P.S. Or maybe there is an inexpensive way to keep track of the types of the
entire array on element assignment?
P.P.S. Can someone please explain and give an example of how generics would
make this need moot? I do not get why that would be the case...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Warn when declaring required parameter afteroptionalone
Error(in PHP 8) after warning or deprecation in 7.xnything more preferred… --- Sent from Mail for Windows 10 From: Olumide Samson Sent: Saturday, January 11, 2020 2:42 PM To: Niklas Keller; Nikita Popov Cc: Bob Weinand; PHP internals Subject: RE: [PHP-DEV] Warn when declaring required parameter afteroptionalone Should it be a warning or an error? --- Sent from Mail for Windows 10 From: Niklas Keller Sent: Saturday, January 11, 2020 2:35 PM To: Nikita Popov Cc: Bob Weinand; PHP internals Subject: Re: [PHP-DEV] Warn when declaring required parameter after optionalone Hi Nikita, while this is a rather small change, it has quite some BC impact, as not all old code has been adjusted to run on PHP 7.1+ only using nullable types. I'd like to see an RFC with a vote for this. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Request for RFC karma wiki account
Hi all, After the feedback on 'Typed array properties V2', I'd like to start fleshing out an RFC for which I understand Karma must be granted by @PHP internals Many thanks, Aran
Re: [PHP-DEV] Warn when declaring required parameter after optional one
Hi all, Whilst I totally see the benefits of this, I'm not sure if this is a job for PHP itself, rather a coding standard enforced optionally by something like PHPCS. It's certainly a bad practice, but I'm not sure the benefit will be worth the refactors required. I feel we might be an interesting example, however, it'd cause us a lot of pain for the following reason: We have a portion of our codebase (shared over hundreds of websites) which is symlinked into each of the websites so the core functionality can be easily updated when required on all sites. These sites are staggered at present across multiple PHP versions whilst being migrated (and due to the number of sites to migrate, they will be for some time). If this change were to come into effect, the same code we've safely had symlinked running across multiple PHP versions would suddenly become incompatible on the latest version, with no easy way to be suppressed which would mean we have to fork things and maintain two codebases. I appreciate this isn't likely to be a normal workflow for people, but it is an example of how it could cause unintended pain. Just my thoughts anyway. Cheers, Aran On Fri, 17 Jan 2020 at 18:00, Nikita Popov wrote: > On Sat, Jan 11, 2020 at 2:35 PM Niklas Keller wrote: > > > Hi Nikita, > > > > while this is a rather small change, it has quite some BC impact, as > > not all old code has been adjusted to run on PHP 7.1+ only using > > nullable types. > > > > I'd like to see an RFC with a vote for this. > > > > Regards, > > Niklas > > > > I was interested in seeing how prevalent this pattern, is, so I ran some > analysis on the top 2k composer packages. I found 527 signatures that would > throw a deprecation warning with this change. Of these 187 are potentially > used as "poor man's nullable types" (the optional argument has both a type > and a null default), while the other 340 are definite bugs. > > Regards, > Nikita >
Re: [PHP-DEV] Warn when declaring required parameter after optional one
On Sat, Jan 11, 2020 at 2:35 PM Niklas Keller wrote: > Hi Nikita, > > while this is a rather small change, it has quite some BC impact, as > not all old code has been adjusted to run on PHP 7.1+ only using > nullable types. > > I'd like to see an RFC with a vote for this. > > Regards, > Niklas > I was interested in seeing how prevalent this pattern, is, so I ran some analysis on the top 2k composer packages. I found 527 signatures that would throw a deprecation warning with this change. Of these 187 are potentially used as "poor man's nullable types" (the optional argument has both a type and a null default), while the other 340 are definite bugs. Regards, Nikita
Re: [PHP-DEV] Typed array properties V2
On Fri, Jan 17, 2020, at 7:53 AM, Robert Hickman wrote: > > So essentially we are talking about generics. I think it's the best time to > > do so... Maybe our wishes come true soon? ;) > > > > Given that the general trend is towards making PHP more statically > typed and very java/C# like, why not just ditch PHP and use one of the > aforementioned languages? Because those languages suck for scripted use. For shared-nothing scripting, PHP beats the pants off of them. That doesn't mean we can't continue PHP's fine tradition of stealing good ideas liberally from every language we can find. We can and should do so. (Whether we adopt Generics in the Java.C#/C++ style or pull from some other language is a separate debate.) cf: https://24daysindecember.net/2019/12/06/growing-gradually-in-php/ --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who are the current eligible voters?
> On Jan 16, 2020, at 06:47, Aleksander Machniak wrote: > > On 15.01.2020 21:15, Nikita Popov wrote: >> Yes, having a php.net account is sufficient. Additionally there are 28 >> users in the wiki in the "phpcvs" group, which I *think* means they can >> also vote. >> >> Based on master.php.net data, the number of people who are eligible for >> voting is approximately 1900. The usual turnout for RFC votes is more like >> 30. If it's something very controversial, maybe 100. >> >> People aren't kidding when they say it's easy to get an RFC vote -- but in >> reality, there's simply very little interest ;) > > This code > https://github.com/php/web-wiki/blob/9bc9ba2c3d2d0d26ab510e4959466ab8680b7de7/dokuwiki/lib/plugins/doodle/syntax.php#L226 > suggests above statements are false. The code says that wiki users who are in the “admin,” “phpcvs,” or “voting” groups are able to vote. A wiki account shows up in the “phpcvs” group if they login using their master.php.net account: https://github.com/php/web-wiki/blob/9bc9ba2c3d2d0d26ab510e4959466ab8680b7de7/dokuwiki/lib/plugins/phpcvs/auth.php#L44-L62 In that code, you can see that they automatically have the “phpcvs” group applied. According to this code for master.php.net, a user account is considered approved if they have `cvsaccess` set to 1: https://github.com/php/web-master/blob/0e511803a5fdc430897d53e76d4eaeea407f1e1e/manage/users.php#L335-L337 So, all approved php.net accounts are eligible to vote, which is currently 1858 accounts. -Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] Typed array properties V2
On Fri, Jan 17, 2020, 2:54 PM Robert Hickman wrote: > > So essentially we are talking about generics. I think it's the best time > to > > do so... Maybe our wishes come true soon? ;) > > > > Given that the general trend is towards making PHP more statically > typed and very java/C# like, why not just ditch PHP and use one of the > aforementioned languages? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Who's this? How does this feature means PHP becoming more static type language? Does adding strict typing features remove any dynamic type features of the language? Nope, this still dynamic typing coz it can do both as the need demands.
Re: [PHP-DEV] Typed array properties V2
> So essentially we are talking about generics. I think it's the best time to > do so... Maybe our wishes come true soon? ;) > Given that the general trend is towards making PHP more statically typed and very java/C# like, why not just ditch PHP and use one of the aforementioned languages? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Variable syntax tweaks
On Thu, Jan 16, 2020 at 10:12 AM Claude Pache
wrote:
>
>
> > Le 7 janv. 2020 à 11:23, Nikita Popov a écrit :
> >
> > Hi internals,
> >
> > I'd like to propose a small RFC, which addresses a few minor issues that
> > have not been handled by the original "uniform variable syntax" RFC:
> >
> > https://wiki.php.net/rfc/variable_syntax_tweaks
> >
> > This is all about edge cases of edge cases, of course. I think the only
> > part here that is not entirely straightforward and may need some
> discussion
> > is how arbitrary expression support for instanceof should be handled.
> >
> > Regards,
> > Nikita
>
> Hi,
>
> The RFC looks good for me, except for one point. Concerning the arbitrary
> expression support for `new` and `instanceof`, I strongly think that the
> most consistant choice for delimiters among “(...)” (parentheses) and
> “{...}” (braces) is not braces “{...}”, but parentheses “(...)”. Your
> argument is based on the position of the expression (RHS vs LHS). My
> argument is based on the type (in a broad sense) of the thing that the
> expression is supposed to represent.
>
> The braces are used when the expression is expected to represent:
>
> * a variable name: `${...}`
> * a property name: `$x->{...}` — `X::${...}`
> * a method name: `$x->{...}()` — `X::{...}()`
>
> In all those cases, the expression inside `{...}` must evaluate to a
> string, and will be interpreted as a name.
>
> On the other hand, the parentheses are used when the expression is
> expected to represent:
>
> * an array: `(...)["key"]`
> * an object: `(...)->prop` — `()->meth()` — `clone (...)`
> * a function: `(...)($arg)`
> * a class: `(...)::KONST` — `(...)::${statProp}` — `(...)::${statMeth}()`
>
> In the first two cases, the expected entity, “array” or “object”, is a
> first-class value, and the expression inside `(...)` will be interpreted as
> such.
>
> The last two cases are more interesting. For the ”function” cases, it can
> be:
> * a string representing a function (interpreted as the fully qualified
> name of a function);
> * an array `[ $obj, "meth" ]`, `[ "klass", "meth" ]` or a string
> "klass::meth" representing a method;
> * a closure or another object implementing the magic __invoke() method.
>
> For the “class” case, it can be:
> * a string representing a class (interpreted as the fully qualified name
> of a class);
> * an instance of a class.
>
> In those cases, the expected entity may be a first-class citizen (a
> closure, an instance of a class), or an entity that, although not a
> first-class citizen, is unambiguously(*) represented by some other
> first-class value (a function by their fully qualified name, etc.) and
> could have been reasonably designed as first-class citizen (and indeed, a
> function may be replaced with a Closure object with the same functionality).
>
> (*) (For the sake of not complicating the argument, I’m ignoring callables
> whose meaning depends on context such as `["self", "foo"]`.)
>
> You rightly noted that the braces `{...}` are used exclusively on the RHS;
> that follows from their meaning: a bare name has no significance out of
> context, where the context is whether it is a function name, or whether it
> is a property/method name and of which object/class the property/method is,
> or etc. That context is more naturally provided before (at the left of) the
> name.
>
> On the other hand the parentheses `(...)` are often used on the LHS: this
> place is the natural place for an entity (an object, a class, etc.) that
> don’t need more context to be well-defined, and that serves as target for
> some action (call the function, look up the property of an object, etc.)
> However, although the entity is often placed at LHS, this is not
> systematic; consider f.e. `clone $obj`, which is quite similar to `new
> klass`.
>
Thanks for the feedback Claude.
I think you make a compelling case, and have updated the RFC to use "new
(expr)" and "$x instanceof (expr)" syntax instead.
Regards,
Nikita
Re: [PHP-DEV] Typed array properties V2
Hi, So essentially we are talking about generics. I think it's the best time to do so... Maybe our wishes come true soon? ;) Cheers, Máté
Re: [PHP-DEV] Typed array properties V2
Hello all It's a much-requested feature for years and years. My first thought was "we need generics, not this" but than I took 5 minutes to actually think about it. While the same, and much more, can be achieved with generics, it's a difficult feature to implement. There have been several RFCs for generics in the past, which failed. I know Levi Morisson was, at one point, looking at adding support for generics only in traits, because it's difficult to add them in other places. While I still think generics would be a great feature, I now also believe it's worth looking at an "array of" type as something standalone. I've got no clue about the technical implications, but maybe suprting "array of" syntax is a lot more easy than full blown generics? Looking at my day to day work with PHP, I'dsay "array of" types would solve ~80% of my problems with PHP's current type system, and I figure there are lots of developers in a similar situation. If I remember correct from my college days, Java also supports both styles: Int[] and ArrayList. All that to say that maybe it's worth the effort looking at "array of" types as something different than generics? Kind regards Brent > On 17 Jan 2020, at 08:50, Aran Reeks wrote: > > Hi Internals, > > I'd like to kick off a conversation to capture everyone else's thoughts on > tweaking / improving typed properties for arrays (for a PHP 8.x release). > > With all the work done lately to greatly improve the type support in PHP > (which is amazing by the way), I'm finding for the most part, I'm no longer > needing to Docblock as much of my code which is lovely. > > That said, there's a common use case that keeps me going back to them which > I think would be a good thing for PHP to try and solve as a language > feature - better typing of arrays to type their properties. > > IDEs like PHPStorm handle this structure already hence sticking to that as > a starting point... > > @returns []int > > This would designate the return of an array where all its keys are that of > the int type, but it works for any type. > > With that in mind, it might also make sense to allow a shorthand array > alias for array types anyway - array -> []. > > To use actual PHP examples, this would mean the following would be > supported: > > // Typed array properties ...values would follow any existing PHO type > function returnsIntArray(): []int; > function returnsClassArray(): []Class; > > // The same outcome > function returnsArray(): array; > function returnsArray(): []; > > I welcome all your thoughts on this proposal. > > Many thanks, > Aran -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
