Re: [PHP-DEV] Typed array properties V2
Am 17.01.2020 um 08:50 schrieb Aran Reeks: @returns []int int[] etc. is common-place, but I have never seen []int. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Typed array properties V2
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
Re: [PHP-DEV] Bump required libcurl version to 7.17.1
On 12.01.2020 at 23:56, G. P. B. wrote: > On Sun, 12 Jan 2020 at 23:33, Levi Morrison via internals < > internals@lists.php.net> wrote: > >> In other words, I recommend against *requiring* the latest curl >> version and but do recommend bumping the minimum up to at least v7.19. >> Unless we really need something from newer versions (which it doesn't >> look like we do), anything newer than 7.29 would just cause friction >> for people building from source. > > As this is targeting PHP 8 I would say 7.29 would be better IMHO as > RHEL/CentOS 6 EOL is November 30, 2020 [1] [2] which means it would be > EOL just after PHP 8 is released (if PHP 8 is release on the yearly > schedule). > > [1] https://endoflife.software/operating-systems/linux/centos > [2] https://access.redhat.com/discussions/2399461 I agree that it makes sense to bump to >= 7.29.0 for PHP 8.0.0, and have updated the PR accordingly. Thanks, Christoph -- 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?
Nikita Popov in php.internals (Thu, 16 Jan 2020 15:51:06 +0100): > >If you don't know your php.net account password, request a new one at >https://master.php.net/forgot.php. Thanks. That one worked. Just curious: why did the wiki send me an unusable Wikidocu password? -- Jan -- 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 Thu, Jan 16, 2020 at 3:45 PM Jan Ehrhardt wrote: > "Christoph M. Becker" in php.internals (Thu, 16 Jan 2020 14:16:21 > +0100): > >On 16.01.2020 at 13:18, Jan Ehrhardt wrote: > > > >> And I still cannot vote. This discussion prompted me to request a > >> password. I got a DokuWiki password, but logging in on > >> https://wiki.php.net/?do=login resulted in > >> > >> | Sorry, username or password was wrong. > > > >You are supposed to be able to login with your php.net account's > password. > > I do not have any password. The only one I could request was through > https://wiki.php.net/start?do=resendpwd > Then I got a confirmation link and after that a password in a mail > message. That password did not work with the username 'ehrhardt' (which > is OK, because I used that one for rewuesting the password). > -- > Jan > If you don't know your php.net account password, request a new one at https://master.php.net/forgot.php. If you have a php.net account, you need to use the php.net password to log in on wiki.php.net (and all other php.net services). The accounts created directly on wiki.php.net are only used by people who don't have a php.net account. Nikita
Re: [PHP-DEV] Who are the current eligible voters?
"Christoph M. Becker" in php.internals (Thu, 16 Jan 2020 14:16:21 +0100): >On 16.01.2020 at 13:18, Jan Ehrhardt wrote: > >> And I still cannot vote. This discussion prompted me to request a >> password. I got a DokuWiki password, but logging in on >> https://wiki.php.net/?do=login resulted in >> >> | Sorry, username or password was wrong. > >You are supposed to be able to login with your php.net account's password. I do not have any password. The only one I could request was through https://wiki.php.net/start?do=resendpwd Then I got a confirmation link and after that a password in a mail message. That password did not work with the username 'ehrhardt' (which is OK, because I used that one for rewuesting the password). -- Jan -- 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?
Am 16.01.2020 um 13:52 schrieb Paul M. Jones: Anyone have ideas on how (or from where) the `$INFO['userinfo']['grps']` values get populated? I would guess from the database https://github.com/php/web-wiki/blob/9bc9ba2c3d2d0d26ab510e4959466ab8680b7de7/dokuwiki/lib/plugins/authpdo/auth.php#L208 and https://github.com/php/web-wiki/blob/9bc9ba2c3d2d0d26ab510e4959466ab8680b7de7/dokuwiki/lib/plugins/authpdo/auth.php#L570 -- 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 16.01.2020 at 13:18, Jan Ehrhardt wrote: > tyson andre in php.internals (Thu, 16 Jan 2020 03:02:24 +): >> Olumide Samson in php.internals (Wed, 15 Jan 2020 22:06:04 +0100): >>> Wow. From a participation standpoint that seems pretty pathetic. If 30 >>> is the average that means most people never vote. >>> >>> I would have assumed that having a vote would mean that people would be >>> expected to vote periodically or if not then loose the privilege. >> >> How many of the 1900 are aware that they're eligible to vote? > > I was not. To my surprise Rasmus gave me a php.net account back in > November 2019, without a explicit request. You've requested that account in August, 2018. It just took a while to get approved. :) > And I still cannot vote. This discussion prompted me to request a > password. I got a DokuWiki password, but logging in on > https://wiki.php.net/?do=login resulted in > > | Sorry, username or password was wrong. You are supposed to be able to login with your php.net account's password. -- Christoph M. Becker -- 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. *That's* the kind of thing I had I mind. Good find! Anyone have ideas on how (or from where) the `$INFO['userinfo']['grps']` values get populated? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- 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 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. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- 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?
tyson andre in php.internals (Thu, 16 Jan 2020 03:02:24 +): > Olumide Samson in php.internals (Wed, 15 Jan 2020 22:06:04 +0100): >> Wow. From a participation standpoint that seems pretty pathetic. If 30 >> is the average that means most people never vote. >> >> I would have assumed that having a vote would mean that people would be >> expected to vote periodically or if not then loose the privilege. > >How many of the 1900 are aware that they're eligible to vote? I was not. To my surprise Rasmus gave me a php.net account back in November 2019, without a explicit request. And I still cannot vote. This discussion prompted me to request a password. I got a DokuWiki password, but logging in on https://wiki.php.net/?do=login resulted in | Sorry, username or password was wrong. -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Variable syntax tweaks
> 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`.
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
