[PHP-DEV] What to do with "$array[foobar]"?

Hi internals, PHP has a couple of legacy string interpolation syntaxes, the most egregious being "$array[foobar]". The issue with this syntax is that the array key is not quoted, is required to be not quoted and is silently accepted. We've been fighting back against unquoted strings for a long

Re: [PHP-DEV] Initializing constants once, with code?

On Wed, 8 Jan 2020 at 20:28, Mike Schinkel wrote: > > On Jan 8, 2020, at 5:48 AM, Rowan Tommins > wrote: > > > > I think immutable variables very much address the use cases you're trying > > to address, except for the additional requirement about which syntax > access > > should use. > > In the

[PHP-DEV] PHP 7.4.2RC1 is available for testing

PHP 7.4.2RC1 has just been released and can be downloaded from: Or use the git tag: php-7.4.2RC1 Windows binaries are available at: Please test it carefully, and report any bugs in the bug system at .

[PHP-DEV] PHP 7.3.14RC1 is available for testing

PHP 7.3.14RC1 has just been released and can be downloaded from: Or use the git tag: php-7.3.14RC1 Windows binaries are available at: Please test it carefully, and report any bugs in the bug system. 7.3.14 should be expected

Re: [PHP-DEV] What to do with "$array[foobar]"?

On Thu, Jan 9, 2020 at 12:12 PM Rowan Tommins wrote: > On Thu, 9 Jan 2020 at 10:48, Nikita Popov wrote: > > > PHP has a couple of legacy string interpolation syntaxes, the most > > egregious being "$array[foobar]". The issue with this syntax is that the > > array key is not quoted, is required

Re: [PHP-DEV] zend_call_method with arguments passed by reference

On Wed, Jan 8, 2020 at 4:18 PM wrote: > Thank you for your answer Nikita. > Can you please give me more details what you mean? I can try that approach. > zend_call_method copies the args to params array which is assigned to > zend_fcall_info fci. > I can pass there for example "test" zval

Re: [PHP-DEV] Warn when declaring required parameter after optional one

Am 09.01.2020 um 13:26 schrieb Nikita Popov: What do you think? I would prefer erroring out over just emitting a warning. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Allow ::class on objects

Hi internals, Another small RFC, to allow $object::class syntax: https://wiki.php.net/rfc/class_name_literal_on_object Regards, Nikita

Re: [PHP-DEV] What to do with "$array[foobar]"?

On Thu, 9 Jan 2020 at 10:48, Nikita Popov wrote: > PHP has a couple of legacy string interpolation syntaxes, the most > egregious being "$array[foobar]". The issue with this syntax is that the > array key is not quoted, is required to be not quoted and is silently > accepted. > > ... > > What do

[PHP-DEV] How to serialize op_array

Hi, How to serialize op_array ? I tried with zend_file_cache.c but getting error. Is there any function available to serialize and store op_array then reuse op_array from disk(file). Regards

[PHP-DEV] Warn when declaring required parameter after optional one

Hi internals, I've created https://github.com/php/php-src/pull/5067 to make code like function test($foo = null, $bar) {} throw a warning: Warning: Required parameter $bar follows optional parameter Historically, having an "optional" parameter before a required one was useful for poor

Re: [PHP-DEV] Warn when declaring required parameter after optional one

Hey, While I generally agree that it likely is a bug in new code, I would rather deprecate it than warn or even error: the change would make it impossible to retain a type without warning while preserving compatibility with an old PHP version and making incremental migrations harder (would

Re: [PHP-DEV] Warn when declaring required parameter after optionalone

> I could understand a warning or deprecation in a minor release, but as there's already so many engine level exceptions landing in 8.0, I think it makes sense to throw this on the pile as well to be swept up in the same pass of migrations that people do in preperation for 8.0. If this would've

Re: [PHP-DEV] [RFC] Allow ::class on objects

Another small RFC, to allow $object::class syntax: https://wiki.php.net/rfc/class_name_literal_on_object Hi Nikita, Glad to see enhancements to ::class. Open questions, given: class Foo {} $foo = new Foo; echo $foo::class; // Foo $fooClass = Foo::class; echo

Re: [PHP-DEV] [RFC] Static return type

On Thu, 9 Jan 2020 at 15:22, Andreas Hennings wrote: > > However, $this is not a real type, and it is unclear what the advantage > of specifying $this rather than static would be from a type system level > perspective. > > Perhaps not from a "type system level", but from a more broad "enforced >

RE: [PHP-DEV] zend_call_method with arguments passed by reference

Thanks a lot Nikita, that’s it. I was not aware of no_separation influence, it was set to 1 in zend_call_method both in PHP5 and PHP7 so I didn't touch it during migration. I need to copy the arguments properly back now but basically it's working. Thanks again, Martin -Original

Re: [PHP-DEV] [RFC] Static return type

On Wed, Jan 8, 2020, at 5:42 AM, Nikita Popov wrote: > Hi internals, > > I would like to propose the following RFC, which allows using "static" as a > return type: > > https://wiki.php.net/rfc/static_return_type > > While I'm personally not a fan of late static binding, we do support it and >

Re: [PHP-DEV] [RFC] Static return type

> However, $this is not a real type, and it is unclear what the advantage of specifying $this rather than static would be from a type system level perspective. Perhaps not from a "type system level", but from a more broad "enforced contract" level. E.g. IDEs or code inspection tools can warn if a

Re: [PHP-DEV] [RFC] Static return type

> Of course this ": $this" could be added later in the future. > But this would have the risk that people start adding ": static" on methods > that really return $this. > I second $this. I also would like to be able to declare `function foo(): $this` at the same time as `function foo(): static`

Re: [PHP-DEV] Warn when declaring required parameter after optionalone

On 09/01/2020 12:31, Sebastian Bergmann wrote: I would prefer erroring out over just emitting a warning. I'm in agreement with Sebastian, a compile time error is the way to go. I could understand a warning or deprecation in a minor release, but as there's already so many engine level

Re: [PHP-DEV] Warn when declaring required parameter after optional one

Am 09.01.2020 um 13:31 schrieb Sebastian Bergmann: I would prefer erroring out over just emitting a warning. What I meant, of course, was deprecation (or warning) first before erroring out. Sorry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Warn when declaring required parameter after optional one

On Thu, Jan 9, 2020 at 2:41 PM Bob Weinand wrote: > Hey, > > While I generally agree that it likely is a bug in new code, I would > rather deprecate it than warn or even error: the change would make it > impossible to retain a type without warning while preserving compatibility > with an old PHP

Re: [PHP-DEV] [RFC] Allow ::class on objects

> On Jan 9, 2020, at 5:27 AM, Nikita Popov wrote: > > Hi internals, > > Another small RFC, to allow $object::class syntax: +1 Along those lines, is there any consideration of adding ::interface and ::trait, where applicable? -Mike -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC] Static return type

On Thu, 9 Jan 2020 at 16:31, Nikita Popov wrote: > On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins > wrote: > > > On Thu, 9 Jan 2020 at 14:23, Andreas Hennings > wrote: > > > > > > However, $this is not a real type, and it is unclear what the > advantage > > > of specifying $this rather than

Re: [PHP-DEV] [RFC] Static return type

On Thu, 9 Jan 2020 at 14:23, Andreas Hennings wrote: > > However, $this is not a real type, and it is unclear what the advantage > of specifying $this rather than static would be from a type system level > perspective. > > Perhaps not from a "type system level", but from a more broad "enforced >

[PHP-DEV] Properly validate abstract methods in traits

Hi internals, I've prepared https://github.com/php/php-src/pull/5068 to fix validation of abstract methods inside traits for PHP 8. To provide some context, the situation is currently pretty weird... when you add an abstract method in a trait, you obviously do that because the trait requires

Re: [PHP-DEV] [RFC] Static return type

On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins wrote: > On Thu, 9 Jan 2020 at 14:23, Andreas Hennings wrote: > > > > However, $this is not a real type, and it is unclear what the advantage > > of specifying $this rather than static would be from a type system level > > perspective. > > > >

Re: [PHP-DEV] Initializing constants once, with code?

> On Jan 9, 2020, at 4:38 AM, Rowan Tommins wrote: > Sorry, I don't see it that way. To my mind, the universal use case here is > "initialise some value once and then access it from the program"; the > syntax is secondary to that. > > Evidently, you see those priorities differently; I don't

Re: [PHP-DEV] [RFC] Allow ::class on objects

> On Jan 9, 2020, at 3:29 PM, Ralph Schindler > wrote:How would you get the right semantics out of $object::interface, or > $object::trait, and/or do you have an example of what you're expecting? Sorry, I was only thinking about using it on Interface and Trait names, not on objects. I have a

Re: [PHP-DEV] [RFC] Allow ::class on objects

About the proposal itself of allowing `($expression)::class`, I'd be in favor. > > > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel : > > > > Traits are compiler assisted code copy/paste and not contracts (unlike > > interfaces), so there is no gain in having ::trait. > > It can already be

Re: [PHP-DEV] [RFC] Allow ::class on objects

Along those lines, is there any consideration of adding ::interface and ::trait, where applicable? How would this be applicable? In the context of variables, an object can be only of a single class type, whereas it can be an *instanceof* multiple interfaces (or an extension of other

Re: [PHP-DEV] [RFC] Static return type

Sent from my iPhone > On 9 Jan 2020, at 15:06, Rowan Tommins wrote: > > On Thu, 9 Jan 2020 at 14:23, Andreas Hennings wrote: > >>> However, $this is not a real type, and it is unclear what the advantage >> of specifying $this rather than static would be from a type system level >>

Re: [PHP-DEV] [RFC] Allow ::class on objects

On Thu, Jan 9, 2020 at 3:28 PM Ralph Schindler wrote: > > > Another small RFC, to allow $object::class syntax: > > > > https://wiki.php.net/rfc/class_name_literal_on_object > > Hi Nikita, > > Glad to see enhancements to ::class. Open questions, given: > > > class Foo {} > > $foo = new

Re: [PHP-DEV] [RFC] Allow ::class on objects

On Thu, Jan 9, 2020 at 9:49 PM Nicolas Grekas wrote: > > > $fooClass = Foo::class; >> > echo $foo::class; // TypeError b/c string? >> >> Yes, at least per the current proposal. Whether to allow this is listed as >> an open question. >> > > I missed that part! > > If it could return

Re: [PHP-DEV] [RFC] Allow ::class on objects

Moi Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel : > > > On Jan 9, 2020, at 3:29 PM, Ralph Schindler > > wrote:How would you get the right semantics out of $object::interface, or > > $object::trait, and/or do you have an example of what you're expecting? > > Sorry, I was only thinking

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

On Wed, 8 Jan 2020 at 13:22, Björn Larsson wrote: > Den 2020-01-07 kl. 21:57, skrev George Peter Banyard: > > Greetings internals, > > > > I would like your input on adding TypeError and ValueError exceptions > > to the count() function in respect to the Consistent type errors for > > internal

Re: [PHP-DEV] [RFC] Allow ::class on objects

> Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel : > > Traits are compiler assisted code copy/paste and not contracts (unlike > interfaces), so there is no gain in having ::trait. It can already be referring to using ::class so it makes little sense to disallow ::trait unless there is a

Re: [PHP-DEV] [RFC] Allow ::class on objects

Em qui., 9 de jan. de 2020 às 20:57, Mike Schinkel escreveu: > > > On Jan 9, 2020, at 6:53 PM, Marcio Almada wrote: > > > > Because we would be expanding a construct that already looks > > inappropriate from a purely > > semantic POV with aliases that also would allow inappropriate usage > >

Re: [PHP-DEV] [RFC] Allow ::class on objects

> > Hey Marco, > > > On Jan 9, 2020, at 5:04 PM, Marcio Almada wrote: > > > > Regarding the inclusion of new keywords with similar behavior of `:class`: > > > > Would `Interfaces\FooInterface::trait` or `Traits\FooTrait::interface` > > cause a run time error? If I'm not mistaken `::class` can't

Re: [PHP-DEV] [RFC] Allow ::class on objects

Den tor. 9. jan. 2020 kl. 23.30 skrev Mike Schinkel : > > > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel : > > > > Traits are compiler assisted code copy/paste and not contracts (unlike > > interfaces), so there is no gain in having ::trait. > > It can already be referring to using ::class

Re: [PHP-DEV] [RFC] Allow ::class on objects

> On Jan 9, 2020, at 5:30 PM, Kalle Sommer Nielsen wrote: > > I cannot see any benefits to adding the ::trait syntax (nor the ::interface) > one > besides some OCD issue that you are using ::class on an instance or name > of something that technically is not a class, like in your below >

Re: [PHP-DEV] [RFC] Allow ::class on objects

> On Jan 9, 2020, at 6:53 PM, Marcio Almada wrote: > > Because we would be expanding a construct that already looks > inappropriate from a purely > semantic POV with aliases that also would allow inappropriate usage > `some_function::interface`. > I'd rather have a generally unsatisfying

Re: [PHP-DEV] [RFC] Allow ::class on objects

Hey Marco, > On Jan 9, 2020, at 5:04 PM, Marcio Almada wrote: > > Regarding the inclusion of new keywords with similar behavior of `:class`: > > Would `Interfaces\FooInterface::trait` or `Traits\FooTrait::interface` > cause a run time error? If I'm not mistaken `::class` can't trigger > error

Re: [PHP-DEV] [RFC] Static return type

On 09-01-2020 17:52, Andreas Hennings wrote: > On Thu, 9 Jan 2020 at 16:31, Nikita Popov wrote: > >> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins >> wrote: >> >> An argument could be made that $this does also specify a certain contract >> to the caller: That the API may be used fluently or not

Re: [PHP-DEV] [RFC] Allow ::class on objects

> > $fooClass = Foo::class; > > echo $foo::class; // TypeError b/c string? > > Yes, at least per the current proposal. Whether to allow this is listed as > an open question. > I missed that part! If it could return `string`, that'd be super useful! We have tons of lines of code that