Re: [PHP-DEV] Allow empty property names

[Yasuo Ohgaki]

On Sat, Mar 26, 2016 at 8:08 AM, Yasuo Ohgaki  wrote:
> On Sat, Mar 26, 2016 at 8:00 AM, Marco Pivetta  wrote:
>> On 25 March 2016 at 23:56, Yasuo Ohgaki  wrote:
>>>
>>> Hi all,
>>>
>>> On Sat, Mar 26, 2016 at 5:31 AM, Marco Pivetta  wrote:
>>> > var_dump((object) ['' => 'foo']);
>>> > var_dump((object) ["\0*\0" => 'foo']);
>>> > var_dump((object) ["\0Foo\0" => 'foo']);
>>>
>>> Allowing null char would be too much. We reject null char in path
>>> parameters, it should be rejected like path parameter. IMHO.
>>
>>
>> The sequence "\0*\0" means "protected property", while the sequence
>> "\0Foo\0" means "private property of class Foo": that's been the case for a
>> long time :-)
>
> Oh. Was it? I've never used and encountered this. Thanks.
> I'll avoid null char as I use PostgreSQL JSONB extensively, though.
>
>> Not suggesting allowing "\0" for property names: the example just shows
>> creating a public, private and protected property with an empty name.
>
> Could you show some real world example use cases?

You mean PHP converts private/protected property to this form, not
currently used as JSON string.
I understand your point!

It would be good for PHP users supporting null chars in names, then.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Allow empty property names

[Marco Pivetta]

Hi Yasuo,

On 26 March 2016 at 00:08, Yasuo Ohgaki  wrote:

> > Not suggesting allowing "\0" for property names: the example just shows
> > creating a public, private and protected property with an empty name.
>
> Could you show some real world example use cases?
>

I've been using the "\0\0" approach in a few codegen-related
projects, specifically in ProxyManager (
https://github.com/Ocramius/ProxyManager/blob/master/docs/lazy-loading-ghost-object.md#lazy-initialization-properties-explained
) and GeneratedHydrator ( https://github.com/Ocramius/GeneratedHydrator ).

No user input values involved, though.

See
https://github.com/php/php-src/blob/d3ed75b9ebc998b8cf325e0e3ab954bd10989918/tests/classes/array_conversion_keys.phpt
for the tests inside php-src: the inverse cast is not covered by tests,
though, as there is really little to no use-case for an `stdClass` with
private or protected properties, unless the only purpose is casting it back
into an array.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Allow empty property names

[Yasuo Ohgaki]

Hi Marco,

On Sat, Mar 26, 2016 at 8:00 AM, Marco Pivetta  wrote:
> On 25 March 2016 at 23:56, Yasuo Ohgaki  wrote:
>>
>> Hi all,
>>
>> On Sat, Mar 26, 2016 at 5:31 AM, Marco Pivetta  wrote:
>> > var_dump((object) ['' => 'foo']);
>> > var_dump((object) ["\0*\0" => 'foo']);
>> > var_dump((object) ["\0Foo\0" => 'foo']);
>>
>> Allowing null char would be too much. We reject null char in path
>> parameters, it should be rejected like path parameter. IMHO.
>
>
> The sequence "\0*\0" means "protected property", while the sequence
> "\0Foo\0" means "private property of class Foo": that's been the case for a
> long time :-)

Oh. Was it? I've never used and encountered this. Thanks.
I'll avoid null char as I use PostgreSQL JSONB extensively, though.

> Not suggesting allowing "\0" for property names: the example just shows
> creating a public, private and protected property with an empty name.

Could you show some real world example use cases?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Allow empty property names

[Marco Pivetta]

Hi Yasuo,

On 25 March 2016 at 23:56, Yasuo Ohgaki  wrote:

> Hi all,
>
> On Sat, Mar 26, 2016 at 5:31 AM, Marco Pivetta  wrote:
> > var_dump((object) ['' => 'foo']);
> > var_dump((object) ["\0*\0" => 'foo']);
> > var_dump((object) ["\0Foo\0" => 'foo']);
>
> Allowing null char would be too much. We reject null char in path
> parameters, it should be rejected like path parameter. IMHO.
>

The sequence "\0*\0" means "protected property", while the sequence
"\0Foo\0" means "private property of class Foo": that's been the case for a
long time :-)

Not suggesting allowing "\0" for property names: the example just shows
creating a public, private and protected property with an empty name.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Allow empty property names

[Yasuo Ohgaki]

Hi all,

On Sat, Mar 26, 2016 at 5:31 AM, Marco Pivetta  wrote:
> var_dump((object) ['' => 'foo']);
> var_dump((object) ["\0*\0" => 'foo']);
> var_dump((object) ["\0Foo\0" => 'foo']);

Allowing null char would be too much. We reject null char in path
parameters, it should be rejected like path parameter. IMHO.

Postgresql decided not to allow null char as valid unicode string in
JSONB, for example.
http://www.postgresql.org/docs/9.4/static/datatype-json.html

 The jsonb type also rejects \u (because that cannot be
represented in PostgreSQL's text type)

Postgresql has it own reason why null char cannot be supported. PHP
may suppport it., but I'm 30/70 for supporting null char in property
name because I cannot think of any use cases other than attacking
applications. (BTW, null char in data should be supported as it is
now)

Array key supports binary strings. If there is vote for this change, I
would refrain from voting.
php > var_dump(["abc\0xyz"=>1234]);
php shell code:1:
array(1) {
  'abc\0xyz' =>
  int(1234)
}


var_dump($o->{'123Foo'}); works. ($o->123Foo is illegal)
Therefore, +1 for making $o->{''} to work and removing automatic '' ->
'_empty_' conversion.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Allow empty property names

[Marco Pivetta]

On 25 March 2016 at 21:19, Scott Arciszewski  wrote:

> On Fri, Mar 25, 2016 at 1:45 PM, Nikita Popov 
> wrote:
>
> > Hi internals,
> >
> > Currently we do not allow (*) creating empty property names on objects,
> > i.e.
> >
> > $obj->{''} = 42;
> >
> > is illegal. While empty property names are unlikely to be useful per se,
> > they are problematic for deserialization of foreign formats like JSON. To
> > avoid this issue {"": null} will currently decode to a property named
> > "_empty_" rather than "". Notably, this means that JSON decode and encode
> > do not round-trip (as we do not convert _empty_ back to an empty name
> while
> > encoding).
> >
> > There is no technical reason (that I can see) for keeping this arbitrary
> > restriction. I believe that the original reason for the restriction was
> our
> > use of NUL-prefixed property names for name mangling, combined with the
> > fact that an empty string at the C level happens to "start" with a NUL
> > byte.
> >
> > A patch to drop the restriction and allow empty property names:
> > https://github.com/php/php-src/pull/1836 It does not touch the JSON
> > handling, as there are BC concerns involved there, I leave that to the
> > ext/json maintainer.
> >
> > Any objections to changing this?
> >
> > Regards,
> > Nikita
> >
> > (*) There are roundabout ways to create them anyway.
> >
>
> ​Currently, this succeeds:
>
> $x = json_decode('{"_empty_": "no", "": "foo"}', true);
>
> While this does not:
>
> $x = json_decode('{"_empty_": "no", "": "foo"}');
>
> ​https://3v4l.org/FJHVV
> ​https://3v4l.org/15Sfm​
>
> I'm personally 50/50 on it. ​I think allowing an empty property is kind of
> weird, but not the weirdest behavior PHP allows. Overall, it might
> (ironically enough!) make working with JSON _more_ consistent, and probably
> have other benefits that I can't even imagine at the moment.
>

Note that also that these ones won't work at the moment:

var_dump((object) ['' => 'foo']);
var_dump((object) ["\0*\0" => 'foo']);
var_dump((object) ["\0Foo\0" => 'foo']);

Seems to work consistently on HHVM though: https://3v4l.org/7MO7E

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Allow empty property names

[Scott Arciszewski]

On Fri, Mar 25, 2016 at 1:45 PM, Nikita Popov  wrote:

> Hi internals,
>
> Currently we do not allow (*) creating empty property names on objects,
> i.e.
>
> $obj->{''} = 42;
>
> is illegal. While empty property names are unlikely to be useful per se,
> they are problematic for deserialization of foreign formats like JSON. To
> avoid this issue {"": null} will currently decode to a property named
> "_empty_" rather than "". Notably, this means that JSON decode and encode
> do not round-trip (as we do not convert _empty_ back to an empty name while
> encoding).
>
> There is no technical reason (that I can see) for keeping this arbitrary
> restriction. I believe that the original reason for the restriction was our
> use of NUL-prefixed property names for name mangling, combined with the
> fact that an empty string at the C level happens to "start" with a NUL
> byte.
>
> A patch to drop the restriction and allow empty property names:
> https://github.com/php/php-src/pull/1836 It does not touch the JSON
> handling, as there are BC concerns involved there, I leave that to the
> ext/json maintainer.
>
> Any objections to changing this?
>
> Regards,
> Nikita
>
> (*) There are roundabout ways to create them anyway.
>

​Currently, this succeeds:

$x = json_decode('{"_empty_": "no", "": "foo"}', true);

While this does not:

$x = json_decode('{"_empty_": "no", "": "foo"}');

​https://3v4l.org/FJHVV
​https://3v4l.org/15Sfm​

I'm personally 50/50 on it. ​I think allowing an empty property is kind of
weird, but not the weirdest behavior PHP allows. Overall, it might
(ironically enough!) make working with JSON _more_ consistent, and probably
have other benefits that I can't even imagine at the moment.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises ​

Re: [PHP-DEV] Why is 0x7F permitted in PHP identifiers?

[Ryan Pallas]

On Fri, Mar 25, 2016 at 1:25 PM, Scott Arciszewski 
wrote:

> On Fri, Mar 25, 2016 at 10:20 AM, Andrea Faulds  wrote:
>
> > Hi everyone,
> >
> > Identifiers in PHP source code (including variables names with $) conform
> > to the regex /[_a-zA-Z\x7F-\xFF][_0-9a-zA-Z\x7F-\xFF]*/. Most of this
> regex
> > is pretty standard: it allows alphanumeric ASCII characters and
> > underscores, plus any character with the 8th bit set (presumably to allow
> > any extension of ASCII, such as Latin-1 or UTF-8, to be used).
> >
> > But there's one part of this I find rather curious: why is \x7F included?
> > It's not a high-byte/8-bit character, it's a 7-bit ASCII character, and a
> > control character at that. Unless there's some ASCII extension which
> reuses
> > that value as a printing character, I assume it must have been a mistake
> to
> > include this character. As a control character, it is invisible and
> > difficult to type, and it might do weird things in some terminal
> emulators.
> > I can't see the value in permitting it within an identifier.
> >
> > I've done a little bit of looking around, and I can't find an important
> > ASCII extension which changes what 0x7F does. Given that, I assume it was
> > simply a mistake. But one of you might be able to enlighten me otherwise.
> >
> > I've filed a bug report, and made a patch to fix this in php-src and
> > php-langspec master:
> >
> > https://bugs.php.net/bug.php?id=71897
> >
> > Thanks!
> > --
> > Andrea Faulds
> > https://ajf.me/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> ​Interestingly, extract() skips keys with \x7F: https://3v4l.org/ZC9ZA\
>

Also the keys after the \x7F were not present in HHVM, PHP7, however in
5.5-5.6 you get
[9]=>string(1) ""
along with they key that came after it. That's very strange indeed!


> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises ​
>

Re: [PHP-DEV] Why is 0x7F permitted in PHP identifiers?

[Scott Arciszewski]

On Fri, Mar 25, 2016 at 10:20 AM, Andrea Faulds  wrote:

> Hi everyone,
>
> Identifiers in PHP source code (including variables names with $) conform
> to the regex /[_a-zA-Z\x7F-\xFF][_0-9a-zA-Z\x7F-\xFF]*/. Most of this regex
> is pretty standard: it allows alphanumeric ASCII characters and
> underscores, plus any character with the 8th bit set (presumably to allow
> any extension of ASCII, such as Latin-1 or UTF-8, to be used).
>
> But there's one part of this I find rather curious: why is \x7F included?
> It's not a high-byte/8-bit character, it's a 7-bit ASCII character, and a
> control character at that. Unless there's some ASCII extension which reuses
> that value as a printing character, I assume it must have been a mistake to
> include this character. As a control character, it is invisible and
> difficult to type, and it might do weird things in some terminal emulators.
> I can't see the value in permitting it within an identifier.
>
> I've done a little bit of looking around, and I can't find an important
> ASCII extension which changes what 0x7F does. Given that, I assume it was
> simply a mistake. But one of you might be able to enlighten me otherwise.
>
> I've filed a bug report, and made a patch to fix this in php-src and
> php-langspec master:
>
> https://bugs.php.net/bug.php?id=71897
>
> Thanks!
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
​Interestingly, extract() skips keys with \x7F: https://3v4l.org/ZC9ZA

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises ​

[PHP-DEV] Allow empty property names

[Nikita Popov]

Hi internals,

Currently we do not allow (*) creating empty property names on objects, i.e.

$obj->{''} = 42;

is illegal. While empty property names are unlikely to be useful per se,
they are problematic for deserialization of foreign formats like JSON. To
avoid this issue {"": null} will currently decode to a property named
"_empty_" rather than "". Notably, this means that JSON decode and encode
do not round-trip (as we do not convert _empty_ back to an empty name while
encoding).

There is no technical reason (that I can see) for keeping this arbitrary
restriction. I believe that the original reason for the restriction was our
use of NUL-prefixed property names for name mangling, combined with the
fact that an empty string at the C level happens to "start" with a NUL byte.

A patch to drop the restriction and allow empty property names:
https://github.com/php/php-src/pull/1836 It does not touch the JSON
handling, as there are BC concerns involved there, I leave that to the
ext/json maintainer.

Any objections to changing this?

Regards,
Nikita

(*) There are roundabout ways to create them anyway.

Re: [PHP-DEV] Re: [RFC] [Vote] Short Ternary Assignment Operator

[Sara Golemon]

On Fri, Mar 25, 2016 at 6:44 AM, Nikita Popov  wrote:
> I don't think the current implementation is entirely correct. In particular,
> it doesn't look memory-safe to me. You're doing an RW fetch on the LHS
> first, then evaluate the RHS expression and then ASSIGN to the result of the
> RW fetch. This means you're running user code between the RW fetch and the
> assignment to it. The code of the RHS expression may cause a reallocation of
> the buffer into which the INDIRECT points, making it a dangling pointer.
>
> Something like
>
> $a = [false];
> $a[0] ?:= ($a[''] = 42);
>
> will probably result in valgrinds.
>
Ah, good call.  Back to the drawing board. :)

-Sara

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

[PHP-DEV] Why is 0x7F permitted in PHP identifiers?

[Andrea Faulds]

Hi everyone,

Identifiers in PHP source code (including variables names with $) 
conform to the regex /[_a-zA-Z\x7F-\xFF][_0-9a-zA-Z\x7F-\xFF]*/. Most of 
this regex is pretty standard: it allows alphanumeric ASCII characters 
and underscores, plus any character with the 8th bit set (presumably to 
allow any extension of ASCII, such as Latin-1 or UTF-8, to be used).


But there's one part of this I find rather curious: why is \x7F 
included? It's not a high-byte/8-bit character, it's a 7-bit ASCII 
character, and a control character at that. Unless there's some ASCII 
extension which reuses that value as a printing character, I assume it 
must have been a mistake to include this character. As a control 
character, it is invisible and difficult to type, and it might do weird 
things in some terminal emulators. I can't see the value in permitting 
it within an identifier.


I've done a little bit of looking around, and I can't find an important 
ASCII extension which changes what 0x7F does. Given that, I assume it 
was simply a mistake. But one of you might be able to enlighten me 
otherwise.


I've filed a bug report, and made a patch to fix this in php-src and 
php-langspec master:


https://bugs.php.net/bug.php?id=71897

Thanks!
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Re: [RFC] [Vote] Short Ternary Assignment Operator

[Nikita Popov]

On Fri, Mar 25, 2016 at 4:25 AM, Sara Golemon  wrote:

> On Thu, Mar 24, 2016 at 11:12 AM, Sara Golemon  wrote:
> > After some discussion (and realizing the referenced implementation
> > needed more work that a simple replacement of tokens), I've decided
> > the close this vote, work with Midori on both implementations some
> > more, and reopen at a later time with a complete implementation
> > (possibly combined with ??=)
> >
>
> https://github.com/php/php-src/compare/master...sgolemon:short-ternary.coalesce
>
> I've gone from scratch to implement this branch which doesn't
> introduce any new opcodes, but it does add a new AST kind which is
> compiled into something closely (but not quite) resembling a regular
> short ternary.
>
> It cheats slightly by assuming that since child[0] comes from a
> `variable` in the parser that zend_compile_var() on it will always
> yield IS_CV/IS_VAR, and I've got an assert in to guard on that, but a
> second set of eyes would be nice there.
>
> You'll notice there's a new runtime check in ZEND_JMP_SET to handle
> the IS_INDIRECT case (which I see resulting from the dim/obj paths.
> It's hidden behind an existing check for IS_VAR/IS_CV, so anything
> producing a TMP won't hit it.  Hopefully it's not too harsh.
>
> Based on feedback, I hope to add the ??= version of this
> implementation as another commit and let Midori unify the two RFCs
> into one. (unless someone objects to that)
>

I don't think the current implementation is entirely correct. In
particular, it doesn't look memory-safe to me. You're doing an RW fetch on
the LHS first, then evaluate the RHS expression and then ASSIGN to the
result of the RW fetch. This means you're running user code between the RW
fetch and the assignment to it. The code of the RHS expression may cause a
reallocation of the buffer into which the INDIRECT points, making it a
dangling pointer.

Something like

$a = [false];
$a[0] ?:= ($a[''] = 42);

will probably result in valgrinds.

Nikita

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-03-25

[lp_benchmark_robot]

Results for project PHP master, build date 2016-03-25 06:27:31+02:00
commit: 454ae8a
previous commit:bc9910c
revision date:  2016-03-24 11:09:08+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.27% -0.01%  0.54%  
  7.30%
:-|   Drupal 7.36 cgi -T1  0.17%  0.00% -0.57%  
  4.88%
:-|   MediaWiki 1.23.9 cgi -T5000  0.21%  0.00%  1.05%  
  4.10%
:-|   bench.php cgi -T100  0.07% -0.02% 22.77%  
  0.11%
:-|  micro_bench.php cgi -T10  0.01%  0.02%  6.39%  
  3.05%
:-|  mandelbrot.php cgi -T100  0.10% -0.03% 30.52%  
  5.01%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-03-25/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Combine ??= and ?:= assignment operator rfc's.

[Midori Kocak]

http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html
 


> On 25 Mar 2016, at 13:42, Nikita Popov  wrote:
> 
> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak  > wrote:
> Hi Everyone,
> 
> I think it's better idea to combine those two assignment operator RFC’s. So I 
> am going to close the current one and open ??= with ?:=
> What do you think? And we have to find better names.
> 
> Wishes,
> Midori Kocak
> 
> I'd prefer to keep them separate, or at least keep their votes separate. The 
> ??= operator vote is currently unanimous at 24:0, while the ?:= vote was 
> closed at something like 9:2, so there clearly are differences of opinion 
> regarding these two operators.
> 
> I'll use this chance for some comments on the proposal. I can see the general 
> usefulness of ??=, but right now the RFC is severely underspecified and I'm 
> uncomfortable voting on it in it's current form as so much will depend on the 
> final implementation. So, what do I mean by underspecified?
> 
> The only statement the RFC essentially makes is that $a ??= $b will be the 
> same as $a = $a ?? $b, for variable-expression $a and expression $b. This 
> statement, while a good high-level illustration, does not explain the exact 
> behavior of this operator.
> 
> For example, consider the expression $a[print 'X'] ??= $b. A simple 
> desugaring into $a[print 'X'] = $a[print 'X'] ?? $b will result in 'X' being 
> printed twice. However, this is not how all other existing compound 
> assignment operators behave: They will print X only once, as the LHS is only 
> evaluated once. I assume that ??= would behave the same way.
> 
> However, with ??= the problem becomes more complicated. Let us assume that $a 
> is an ArrayAccess object and consider the expression $a[0] ??= $b. Let us 
> further assume that $x = $a->offsetGet(0) is non-null. Will $a[0] ??= $b 
> result in a call to $a->offsetSet(0, $x)? This is what would normally happen 
> with a compound assignment operator and what would be implied by the 
> desugaring $a[0] = $a[0] ?? $b. However this assignment is not really 
> necessary, as we're just reassigning the same value. So, does the call happen 
> or not? Is the proper desugaring maybe if (!isset($a[0])) $a[0] = $b?
> 
> Let us now assume that $a is a recursive ArrayAccess object with by-reference 
> offsetGet() and consider the expression $a[0][1] ??= expr. For a normal 
> compound assignment operator, this would issue the call sequence
> 
> $b = expr;
> $x =& $a->offsetGet(0);
> $y = $x->offsetGet(1);
> $y OP= $b;
> $x->offsetSet(1, $y);
> 
> Note that we only issue one offsetSet() at the end. We do not refetch $x via 
> $a->offsetGet(0). How would the same work with the ??= operator? As the RHS 
> is evaluated lazily, it is my opinion that only performing the offsetSet() 
> call without refetching $x beforehand would violate PHP's indirection memory 
> model. Additionally as ??= has to fetch offsets in BP_VAR_IS mode, we likely 
> wouldn't be able to write them without refetching anymore.
> 
> So, what would be the desugared call sequence for $a[0][1] ??= expr? 
> Something like this?
> 
> if (!$a->offsetHas(0)) {
> goto assign;
> }
> $x = $a->offsetGet(0);
> if (x === null) {
> goto assign;
> }
> if (!$x->offsetHas(0)) {
> goto assign;
> }
> $y = $x->offsetGet(0);
> if ($y === null) {
> goto assign;
> }
> goto done;
> assign:
> $b = expr;
> $x =& $a->offsetGet(0);
> $x->offsetSet(1, $b);
> done:
> 
> That would be some first thoughts on the issue, though I'm sure there are 
> more subtleties involved. I'd like to see the exact behavior of ??= (and ?:=) 
> specified.
> 
> I'm also pretty sure that writing a patch for this will not be entirely easy. 
> The combination of execute-once LHS side-effects and lazy RHS execution does 
> not translate well to PHP's VM constraints.
> 
> Regards,
> Nikita

Re: [PHP-DEV] Combine ??= and ?:= assignment operator rfc's.

[Nikita Popov]

On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak  wrote:

> Hi Everyone,
>
> I think it's better idea to combine those two assignment operator RFC’s.
> So I am going to close the current one and open ??= with ?:=
> What do you think? And we have to find better names.
>
> Wishes,
> Midori Kocak
>

I'd prefer to keep them separate, or at least keep their votes separate.
The ??= operator vote is currently unanimous at 24:0, while the ?:= vote
was closed at something like 9:2, so there clearly are differences of
opinion regarding these two operators.

I'll use this chance for some comments on the proposal. I can see the
general usefulness of ??=, but right now the RFC is severely underspecified
and I'm uncomfortable voting on it in it's current form as so much will
depend on the final implementation. So, what do I mean by underspecified?

The only statement the RFC essentially makes is that $a ??= $b will be the
same as $a = $a ?? $b, for variable-expression $a and expression $b. This
statement, while a good high-level illustration, does not explain the exact
behavior of this operator.

For example, consider the expression $a[print 'X'] ??= $b. A simple
desugaring into $a[print 'X'] = $a[print 'X'] ?? $b will result in 'X'
being printed twice. However, this is not how all other existing compound
assignment operators behave: They will print X only once, as the LHS is
only evaluated once. I assume that ??= would behave the same way.

However, with ??= the problem becomes more complicated. Let us assume that
$a is an ArrayAccess object and consider the expression $a[0] ??= $b. Let
us further assume that $x = $a->offsetGet(0) is non-null. Will $a[0] ??= $b
result in a call to $a->offsetSet(0, $x)? This is what would normally
happen with a compound assignment operator and what would be implied by the
desugaring $a[0] = $a[0] ?? $b. However this assignment is not really
necessary, as we're just reassigning the same value. So, does the call
happen or not? Is the proper desugaring maybe if (!isset($a[0])) $a[0] = $b?

Let us now assume that $a is a recursive ArrayAccess object with
by-reference offsetGet() and consider the expression $a[0][1] ??= expr. For
a normal compound assignment operator, this would issue the call sequence

$b = expr;
$x =& $a->offsetGet(0);
$y = $x->offsetGet(1);
$y OP= $b;
$x->offsetSet(1, $y);

Note that we only issue one offsetSet() at the end. We do not refetch $x
via $a->offsetGet(0). How would the same work with the ??= operator? As the
RHS is evaluated lazily, it is my opinion that only performing the
offsetSet() call without refetching $x beforehand would violate PHP's
indirection memory model. Additionally as ??= has to fetch offsets in
BP_VAR_IS mode, we likely wouldn't be able to write them without refetching
anymore.

So, what would be the desugared call sequence for $a[0][1] ??= expr?
Something like this?

if (!$a->offsetHas(0)) {
goto assign;
}
$x = $a->offsetGet(0);
if (x === null) {
goto assign;
}
if (!$x->offsetHas(0)) {
goto assign;
}
$y = $x->offsetGet(0);
if ($y === null) {
goto assign;
}
goto done;
assign:
$b = expr;
$x =& $a->offsetGet(0);
$x->offsetSet(1, $b);
done:

That would be some first thoughts on the issue, though I'm sure there are
more subtleties involved. I'd like to see the exact behavior of ??= (and
?:=) specified.

I'm also pretty sure that writing a patch for this will not be entirely
easy. The combination of execute-once LHS side-effects and lazy RHS
execution does not translate well to PHP's VM constraints.

Regards,
Nikita

Re: [PHP-DEV] Add spaceship assignment operator

[Dmitry Stogov]

I hope this is a joke.
Lets try not to reinvent Perl.

Thanks. Dmitry.


From: Nikita Popov 
Sent: Thursday, March 24, 2016 20:50
To: PHP internals
Subject: [PHP-DEV] Add spaceship assignment operator

Hi internals!

For consistency, we should add a spaceship assignment operator:

$a <=>= $b;
// same as
$a = ($a <=> $b);

Additionally, we should add an is-identical assignment operator:

$a  $b;
// same as
$a = ($a === $b);

Thank you for taking this proposal under consideration.

Regards,
Nikita

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

Re: [PHP-DEV] [VOTE] Warn about invalid strings in arithmetic

[Andrea Faulds]

Hi Björn,

Björn Larsson wrote:

Den 2016-03-24 kl. 21:29, skrev Andrea Faulds:
Came to think on a conversation with Sara G last year about introducing
the following operators, namely >==, <== & <==> working exactly like the
existing ones but without type juggling.

Maybe that would alleviate some of the issue here, giving new tools at
hand when writing new or updating existing code?


This is an interesting idea. === and !== avoid type juggling by 
returning FALSE if the types of their operands don't match, so what 
would these hypothetical strict versions of < and > do in that 
situation? One approach would be to order by type, so any integer < any 
float < any string, for example. I think I'd like that, it'd be more 
predictable than PHP's current comparison operators, where "1" < "a" < 
"b" < 1 < "2" < 2.


I'm not sure about those symbols, though. Given their appearance I'd 
think >== and <== would be strict versions of >= and <=, even though I 
think you're proposing them to be strict versions of > and <. But surely 
something could be figured out.


Thanks!

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Combine ??= and ?:= assignment operator rfc's.

[Dan Ackroyd]

On 25 March 2016 at 10:59, Midori Kocak  wrote:
> I think it's better idea to combine those two assignment operator RFC’s. So I 
> am going to close the current one and open ??= with ?:=

Keeping RFCs separate is good in my opinion. In general it allows the
discussions to be clear, and that is particularly true here, as there
are issues with ternaries in PHP that do not affect null coalesce
operators.

But in this case, the vote for ??= is underway. The only reason to
alter the timeline of the vote should be if a severe problem was found
with the RFC. So please leave it to run.

btw I actually think we ought to have someone other than the RFC
author open and close the voting as there have been some votes
opened/closed that have been surprises.

cheers
Dan

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

Re: [PHP-DEV] [VOTE] Warn about invalid strings in arithmetic

[Patrick ALLAERT]

Le jeu. 24 mars 2016 à 21:29, Andrea Faulds  a écrit :

> Hi Patrick,
>
> Patrick ALLAERT wrote:
> > Hi Andrea,
> >
> > Nice work.
> >
> > I'm globally +0.7 on it, there is however a few things that are unclear
> to
> > me:
> >
> > * What happens with an empty string? Warning, notice or even nothing?
> >
> > * Would:
> > 42 + "";
> > produce the same thing than:
> > 42 + null;
> > currently, both are quiet, but both doesn't mean something.
>
> "" is non-numeric, so (42 + "") produces a warning. This RFC doesn't
> touch non-string values, however, so (42 + null) continues to produce no
> error:
>
>  $ sapi/cli/php -r 'var_dump(42 + "");'
>
>  Warning: A non-numeric value encountered in Command line code on line
> 1
>  int(42)
>
>  $ sapi/cli/php -r 'var_dump(42 + null);'
>  int(42)
>
> > * You don't mention the <, >, <= and >= operators, is that intentional?
> > php > var_dump( 42 < "42 bananas" );
> > bool(false)
> > php > var_dump( 42 <= "42 bananas" );
> > bool(true)
> > php > var_dump( 42 > "42 bananas" );
> > bool(false)
> > php > var_dump( 42 >= "42 bananas" );
> > bool(true)
>
> The RFC does mention them in the "Unaffected PHP Functionality" section:
> "It also does not impact the behaviour of type juggling for comparisons."
>
> I can't entirely blame you for missing that, though.
>

I searched on the "<" / ">" chars, that's how I missed it. My bad!


> So, those examples you provided will continue to not produce errors.
> This is deliberate.
>
> > It would be illogic, IMHO, to not take those operators into account and
> > would introduce some inconsistencies, that is why I voted "No" although
> I'm
> > generally ok with the whole idea.
>
> I might like it if we change the behaviour of those operators, but I
> don't think this is the RFC to do it in.
>
> This RFC adds E_NOTICE and E_WARNING errors to certain operators that
> take numbers as inputs and produce numbers as outputs. Arguably, strings
> which are only partly a number, or not a number, are incorrect input for
> these operators, or at the very least unlikely to be intentional on the
> part of the programmer. Therefore, warning the programmer that the
> inputs given were invalid is arguably helpful. I chose to produce
> E_NOTICEs and E_WARNINGs because they are less likely to cause
> backwards-compatibility issues than, for example, a TypeError, and this
> is important given the release process RFC forbids us from breaking
> compatibility in a minor release (like 7.1).
>
> While I think my rationale above for adding warnings makes sense for
> number operators, I don't think it works for the comparison ones. The
> comparison operators all take two values which each can be of any type,
> and there are no particular expectations about what their input should
> be. Since non-well-formed numeric strings aren't invalid input, we don't
> have the case to warn about them here.
>
> What *is* a problem for the comparison operators is how they interpret
> numeric strings, or even that they interpret them at all. A warning also
> doesn't help here. So what would? Well, we could decide on some more
> sensible interpretation of numeric strings. But that would mean that the
> behaviour of the comparison operators would change, a significant
> backwards-compatibility break, and a particularly bad one because it's
> completely silent: there's no runtime warning that the behaviour has
> changed, and no IDE or static analyser could warn you where your code
> might have been affected. It's possible to make these kinds of changes
> sometimes, but we must be very careful about it, and it shouldn't be
> done in a minor release like 7.1. It would also be a controversial
> change, so putting it in this RFC might doom the other changes it makes.
>
> I hope this makes it clearer why I didn't touch the comparison operators
> in this RFC. I think they're a separate, but related issue.
>
> Thanks for asking.
>
> --
> Andrea Faulds
> https://ajf.me/


I understand and follow you on this.
Thanks for clearing everything out.

+1 :)

Patrick

Re: [PHP-DEV] [VOTE] var deprecation

[Christoph Becker]

On 25.03.2016 at 08:12, Dmitry Stogov wrote:

> Java is going to add "var" (http://openjdk.java.net/jeps/286), we are going 
> to remove...

If this JEP is going to pass, "var" will be allowed to replace (local)
*type declarations*.  In PHP "var" is an alternative *visibility
specification*.  That's something quite different.

-- 
Christoph M. Becker


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

[PHP-DEV] Combine ??= and ?:= assignment operator rfc's.

[Midori Kocak]

Hi Everyone,

I think it's better idea to combine those two assignment operator RFC’s. So I 
am going to close the current one and open ??= with ?:=
What do you think? And we have to find better names.

Wishes,
Midori Kocak
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] var deprecation

[Thomas Punt]

Hi Dmitry,

> Java is going to add "var" (http://openjdk.java.net/jeps/286), we are going 
> to remove...

We're not going to remove the "var" keyword, just deprecate its usage in
the context of setting properties as public. The "var" keyword will still
remain a reserved word, and it can therefore still be reused in other places
if we so wish (as has been done with "use" for namespaces, traits, and
closures, as well as "as" in foreach, namespaces, and traits).

So whilst Java is adding "var" for a short-hand declaration via type inference,
it is only applicable to local variables and not properties. Deprecating "var"
in this context for PHP is therefore not really the inverse of what Java is 
doing.

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

Re: [PHP-DEV] [VOTE] Warn about invalid strings in arithmetic

[Yasuo Ohgaki]

Hi,

On Fri, Mar 25, 2016 at 6:25 AM, Björn Larsson
 wrote:
> Came to think on a conversation with Sara G last year about introducing
> the following operators, namely >==, <== & <==> working exactly like the
> existing ones but without type juggling.

>==, <== were not introduced because results are not useful.

For instance,
(10 >== "0") === false
does not make much sense with PHP. It would not solve problem, but
creates new hard to debug problem.

However, raising errors and (10 >== "0") === null make sense. IMO.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Add spaceship assignment operator

[Yasuo Ohgaki]

Hi all,

On Fri, Mar 25, 2016 at 11:25 AM, Pierre Joye  wrote:
> On Fri, Mar 25, 2016 at 12:50 AM, Nikita Popov  wrote:
>> Hi internals!
>>
>> For consistency, we should add a spaceship assignment operator:
>>
>> $a <=>= $b;
>> // same as
>> $a = ($a <=> $b);
>
> I miserably fail to imagine any use case for this.
>
>> Additionally, we should add an is-identical assignment operator:
>>
>> $a  $b;
>> // same as
>> $a = ($a === $b);
>>
>> Thank you for taking this proposal under consideration.
>
> Besides the comment about that one from Sara, I also fail to remotely
> imagine why one would need that.
>
> In short, yes, it is consistent but it is really unreadable, at best.

The same impression.
I suppose there aren't much use cases, are there?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [VOTE] var deprecation

[Dmitry Stogov]

Java is going to add "var" (http://openjdk.java.net/jeps/286), we are going to 
remove...


From: mtko...@gmail.com  on behalf of Mutlu Kocak 

Sent: Thursday, March 24, 2016 22:15
To: Colin O'Dell
Cc: PHP Internals
Subject: Re: [PHP-DEV] [VOTE] var deprecation

+1 var should be deprecated

On Thursday, 24 March 2016, Colin O'Dell  wrote:

> There have been some last-minute concerns raised about var being reserved
> "for future usage".  My intent was that var couldn't be used for
> function/class names IN CASE it was re-used in the future, but not
> encouraging it to be re-used.  I'd assume that reusing it would require a
> separate RFC to pass by a 2/3rds margin.
>
> Does anyone disagree with this interpretation or feel that it should be
> explicitly stated?  Would anyone change their vote from NO to YES if "for
> future usage" was removed (but "reserving it" was kept in)?  Would anyone
> change their vote from NO to YES if the question of "reserving it" could be
> voted on separately?
>
> If so, and we can stop the vote to make these changes, I'd strongly prefer
> to do so.  I'd hate for three words to sink the entire RFC.
>
> (My apologies if this belongs in the discussion thread instead)
>
> Regards,
>
> Colin
>
> On Thu, Mar 24, 2016 at 8:40 AM Colin O'Dell  > wrote:
>
> > Hello everyone,
> >
> > It has been two weeks since discussion started on the RFC to deprecate
> and
> > eventually remove the "var" keyword (and one month since the idea was
> > originally proposed).
> >
> > This RFC has therefore been moved to the "In Voting" state.  Voting will
> > begin immediately and will end in one week.
> >
> > You can find the full RFC (including the proposed patch and automatic
> > upgrade tool) here: https://wiki.php.net/rfc/var_deprecation
> >
> > I encourage everyone to read the RFC and cast your vote towards whichever
> > option you feel is the best for the language and the community.
> >
> > Regards,
> >
> > Colin O'Dell
> >
>


--
Mutlu Koçak | Computer Scientist & Engineer
Mobile: +420775259871
Parizksa 5, Praha 1 Prague Czech Republic

Personal Website: http://www.mtkocak.com

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