Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

I appreciate the work done by Joe, but I vote "no", because the implementation 
is not good enough yet

- it's incompatible with opcache (may be it's not a big problem to fix this)
- typed properties assignment is going to be 2-3 times slower ($obj->x += 2; is 
3 times slower)
- the patch makes slight negative effect even for untyped properties

- the proposed behavior for uninitialized typed properties assumes that they 
have to be checked on each "read". This checks will have to be performed even 
in native JITed code. I don't see a reason for typing if we have to perform 
check on each read anyway.

Thanks. Dmitry.
________
From: Dmitry Stogov <dmi...@zend.com>
Sent: Monday, May 23, 2016 11:30:09 AM
To: Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi Joe,

The performance effect of this implementation is terrible.

Assignment to typed property is 2.3 times slower.
Assignment to untyped property in a class with typed properties is 1.8 times 
slower.

See the benchmark
https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800

Thanks. Dmitry.

From: Joe Watkins <pthre...@pthreads.org>
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

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


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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

Hi Joe,

The performance effect of this implementation is terrible.

Assignment to typed property is 2.3 times slower.
Assignment to untyped property in a class with typed properties is 1.8 times 
slower.

See the benchmark
https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800

Thanks. Dmitry.

From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

The patch "corrupts" opcache shared memory.
PHP crashes with opcache.protect_memory=1.

$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php -d opcache.protect_memory=1 
../Zend/tests/type_declarations/typed_properties_027.php
==900== Memcheck, a memory error detector
==900== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==900== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==900== Command: sapi/cli/php 
../Zend/tests/type_declarations/typed_properties_027.php
==900==
==900==
==900== Process terminating with default action of signal 11 (SIGSEGV)
==900==  Bad permissions for mapped region at address 0xF00FFBC8
==900==at 0x86391FE: zend_verify_weak_scalar_type_hint (zend_execute.c:725)
==900==by 0x8639833: zend_verify_scalar_property_type (zend_execute.c:869)
==900==by 0x8639C2B: zend_verify_property_type (zend_execute.c:938)
==900==by 0x862E46D: zend_std_write_property (zend_object_handlers.c:753)
==900==by 0x8685102: ZEND_ASSIGN_OBJ_SPEC_CV_CONST_OP_DATA_CONST_HANDLER 
(zend_vm_execute.h:42160)
==900==by 0x863F91D: execute_ex (zend_vm_execute.h:426)
==900==by 0x863F9D2: zend_execute (zend_vm_execute.h:471)
==900==by 0x85F38B4: zend_execute_scripts (zend.c:1427)
==900==by 0x85832B7: php_execute_script (main.c:2492)
==900==by 0x86AE2D8: do_cli (php_cli.c:982)
==900==by 0x86AEF42: main (php_cli.c:1352)
==900==






From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

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

[PHP-DEV] "finally" handling refactoring (Bug #72213)

[Dmitry Stogov]

hi,


Please review the path 
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330


I hope, it should completely fix https://bugs.php.net/bug.php?id=72213


I'm going to commit this on Monday.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC][VOTE] Closure from callable

[Dmitry Stogov]

I'm sorry, I didn't follow the RFC discussion.
In general I like the idea, but why not to use Closure constructor?

$f = new Closure("some_func");

would look more readable than

$f = Closure::fromCallable("some_func");

Sorry, if this was already discussed before.

Thanks. Dmitry.


From: Dan Ackroyd 
Sent: Sunday, May 15, 2016 8:29:22 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC][VOTE] Closure from callable

Hello,

I've opened the voting for the Closure from callable RFC -
https://wiki.php.net/rfc/closurefromcallable

Just to note, some people I've spoken to have expressed a desire to
have a more powerful syntax where 'bare' function names are used,
like:

callable(someFunctionName)
callable($this->method)

I fully agree with those people, however I can't see anyway to do that
before PHP 8. It would almost certainly need some clean up of the
allowed syntax to disambiguate what `$this->method` means for:

class Foo {
public $method;
public function method() { }
}

Leaving that top-level function name available for future versions,
where we might be able to support it properly, is one of the reasons
to use the more verbose function name.

cheers
Dan

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


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

[PHP-DEV] Single Stack for all generators

[Dmitry Stogov]

Hi,


Nikita, please review the patch 
https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac

It's the next attempt to use the single stack for all generators.

Now I don't see any problems or BC breaks.


In case "yield" is used as an expression in context of function call. e.g. 
var_dump(yield), engine backups and then restores active call frame chain.


Bob tested the patch on application that intensively uses generators, and 
reported:

15% less L2 cache loads

20% less cycle stalls due to memory subsystem

3% more  CPU_CLOCK_UNHALTED due to additional freeze/restore.


I'm going to commit this patch tomorrow.


Thanks. Dmitry.

[PHP-DEV] outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 11:42 AM, Joe Watkins wrote:

Dmitry,

> Except the fact, that doc-comment content don't have to conform to 
any rules


Nor does an attributes value that is just a string, that isn't 
validated by compiler ... it doesn't *have* to conform to any rules.


That's exactly what people are voting for though, that seems to be 
what people want


I think, different people expect very different functionality and many 
just don't like to introduce replacement for existing doc-comments.
Probably the majority of voters against AST, just don't care about 
applications of this feature (extensible compiler, meta-programming, 
compile-time execution, etc)


I desperately do not want that. I don't see the remarkable difference 
(although there is obviously difference) between attributes that are 
just strings or constant values and doc comments.
The difference is small, but attributes standardize syntax and provide 
standard storage with simple API.

In my view, better to get at least this than nothing.



> and you have to parse it and extract the necessary part of meta 
information every time you need it.


You know that's not really true, there are already hooks and 
mechanisms to "compile" strings in doc comments, I used them literally 
yesterday ...

I don't know about such hooks in the engine. do I miss something? :)



I used them in anticipation that we would get a superior solution some 
time soon ... it now looks like we will not :(


I missed. do you speak about attributes with AST or doc-comments with 
strings.




I don't want to invent ways to parse code, or extract it from anywhere 
... we have a whole engine, an entire folder of code dedicated to 
that, it is nonsensical not to utilize it.


You shouldn't worry about parsing PHP grammar in attribute strings, we 
would just provide an API call in the engine that reuses zendparse() and 
returns AST.

This would take just 10-20 C lines.

Thanks. Dmitry.


Cheers
Joe



On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 05/11/2016 09:57 AM, Joe Watkins wrote:

Dmitry,

> but it's possible to get the same power translating string
values of attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the
consumer of the attributes.

It's already possible to get strings (and so AST) from doc
comments, we don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <> makes
zero sense to me.


Except the fact, that doc-comment content don't have to conform to
any rules, and you have to parse it and extract the necessary part
of meta information every time you need it. It's not a big problem
to do this using Doctrine library, but how are you going to do
this in a compiler hook?




Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:



On 05/11/2016 09:02 AM, Joe Watkins wrote:

Morning Dmitry,

> On the other hand simple string may be parsed into AST
with just one additional call to ast\compile_string().

You're not really suggesting that I write my tools in user
land, are you ? It's me, Joe :)ce


At first days of RFC discussion Sara pointed on over-design
regarding AST.
I saw sense in here comments and updated RFC.



I *only* want attributes as they were originally proposed,
and I can't vote to reflect that.

As discussed in private, what I want is attributes, as
originally proposed, and a hookable compiler; Anything else
is not good enough.


Personally, I'm for AST as well, but it's possible to get the
same power translating string values of attributes into AST
in the hooks.

Thanks. Dmitry.




Cheers
Joe



    On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov
<dmi...@zend.com <mailto:dmi...@zend.com>> wrote:

Hi Joe,


The sense in native support for AST is questionable.


On one hand this allows syntax verification.


On the other hand simple string may be parsed into AST
with just one additional call to ast\compile_string().


Thanks. Dmitry.




*From:* Joe Watkins <pthre...@pthreads.org
<mailto:pthre...@pthreads.org>>
*Sent:* Wednesday, May 11, 2016 7:46:09 AM
*To:* Björn Larsson
*Cc:* Dmitry Stogov; PHP internals
*Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 10:27 AM, Stanislav Malyshev wrote:

Hi!


Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Extending this, it's also possible to get the same power just extracting
phpdocs and applying AST to them.
In general yes, but we don't have grammar for doc-comments, and even 
extracting general string value may be not trivial.


/**
 * Adds two positive numbers
 *
 * @ensures $x + $y >=
 *  0
 * // support for multi-line attribute values?
 * @on_enter @enter_function(__FUNCTION__);
 * '@' sign before enter_function() is a silence operator.
 */
function add($x, $y) {
return $x + $y;
}


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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 09:57 AM, Joe Watkins wrote:

Dmitry,

> but it's possible to get the same power translating string values of 
attributes into AST in the hooks.


Aware.

Enough of the complexity is already the responsibility of the consumer 
of the attributes.


It's already possible to get strings (and so AST) from doc comments, 
we don't need anything new if that's all you want to do.


Essentially, moving something from doc comments to <> makes zero 
sense to me.


Except the fact, that doc-comment content don't have to conform to any 
rules, and you have to parse it and extract the necessary part of meta 
information every time you need it. It's not a big problem to do this 
using Doctrine library, but how are you going to do this in a compiler hook?




Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 05/11/2016 09:02 AM, Joe Watkins wrote:

Morning Dmitry,

> On the other hand simple string may be parsed into AST with
just one additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land,
are you ? It's me, Joe :)ce


At first days of RFC discussion Sara pointed on over-design
regarding AST.
I saw sense in here comments and updated RFC.



I *only* want attributes as they were originally proposed, and I
can't vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.


Personally, I'm for AST as well, but it's possible to get the same
power translating string values of attributes into AST in the hooks.

Thanks. Dmitry.




Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:

Hi Joe,


The sense in native support for AST is questionable.


On one hand this allows syntax verification.


On the other hand simple string may be parsed into AST with
just one additional call to ast\compile_string().


Thanks. Dmitry.



*From:* Joe Watkins <pthre...@pthreads.org
<mailto:pthre...@pthreads.org>>
*Sent:* Wednesday, May 11, 2016 7:46:09 AM
    *To:* Björn Larsson
*Cc:* Dmitry Stogov; PHP internals
*Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not
include support for AST, that's a completely different feature.

As it is, I have to vote yes in favour of AST, but it may
be counted as a vote in favour of attributes without AST ...

This doesn't seem right ... I don't want attributes
without AST, and there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson
<bjorn.x.lars...@telia.com
<mailto:bjorn.x.lars...@telia.com>> wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:



On 05/11/2016 12:29 AM, Björn Larsson wrote:

    Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a
smart tool for PHP extension, but it's not
going to be the end of the world, if we
decided to live with doc-comments only.


Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking
at the
result, my view is that that Annotation is a
better naming
then Attributes. Any hope in changing it?


The more I listen to arguments of adepts of existing
PHP annotation systems, the more I think, that "PHP
attributes" is the right name for this proposal.
This feature is not just for PHP annotation systems.


Thats a fair point, so Annotation it's not. Still, when I
hear PHP
attributes I associate it with class / function
attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn



-- 
PHP Internals - PHP Runtime Development Mailing List

To unsubscribe, visit:
<http://www.php.net/unsub.php>http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 09:02 AM, Joe Watkins wrote:

Morning Dmitry,

> On the other hand simple string may be parsed into AST with just one 
additional call to ast\compile_string().


You're not really suggesting that I write my tools in user land, are 
you ? It's me, Joe :)ce


At first days of RFC discussion Sara pointed on over-design regarding AST.
I saw sense in here comments and updated RFC.



I *only* want attributes as they were originally proposed, and I can't 
vote to reflect that.


As discussed in private, what I want is attributes, as originally 
proposed, and a hookable compiler; Anything else is not good enough.


Personally, I'm for AST as well, but it's possible to get the same power 
translating string values of attributes into AST in the hooks.


Thanks. Dmitry.



Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:


Hi Joe,


The sense in native support for AST is questionable.


On one hand this allows syntax verification.


On the other hand simple string may be parsed into AST with just
one additional call to ast\compile_string().


Thanks. Dmitry.



*From:* Joe Watkins <pthre...@pthreads.org
<mailto:pthre...@pthreads.org>>
*Sent:* Wednesday, May 11, 2016 7:46:09 AM
*To:* Björn Larsson
*Cc:* Dmitry Stogov; PHP internals
*Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include
support for AST, that's a completely different feature.

As it is, I have to vote yes in favour of AST, but it may be
counted as a vote in favour of attributes without AST ...

This doesn't seem right ... I don't want attributes without
AST, and there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson
<bjorn.x.lars...@telia.com <mailto:bjorn.x.lars...@telia.com>> wrote:

    Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:



On 05/11/2016 12:29 AM, Björn Larsson wrote:

    Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart
tool for PHP extension, but it's not going to be
the end of the world, if we decided to live with
doc-comments only.


Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?


The more I listen to arguments of adepts of existing PHP
annotation systems, the more I think, that "PHP
attributes" is the right name for this proposal.
This feature is not just for PHP annotation systems.


Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn



-- 
PHP Internals - PHP Runtime Development Mailing List

To unsubscribe, visit: http://www.php.net/unsub.php
<http://www.php.net/unsub.php>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

Hi Joe,


The sense in native support for AST is questionable.


On one hand this allows syntax verification.


On the other hand simple string may be parsed into AST with just one additional 
call to ast\compile_string().


Thanks. Dmitry.



From: Joe Watkins <pthre...@pthreads.org>
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support for 
AST, that's a completely different feature.

As it is, I have to vote yes in favour of AST, but it may be counted as a 
vote in favour of attributes without AST ...

This doesn't seem right ... I don't want attributes without AST, and there 
is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson 
<bjorn.x.lars...@telia.com<mailto:bjorn.x.lars...@telia.com>> wrote:
Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:


On 05/11/2016 12:29 AM, Björn Larsson wrote:
Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
it's not going to be the end of the world, if we decided to live with 
doc-comments only.


Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation systems, 
the more I think, that "PHP attributes" is the right name for this proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn



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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 12:29 AM, Björn Larsson wrote:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:


Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP 
extension, but it's not going to be the end of the world, if we 
decided to live with doc-comments only.



Thanks. Dmitry.


Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?


The more I listen to arguments of adepts of existing PHP annotation 
systems, the more I think, that "PHP attributes" is the right name for 
this proposal.

This feature is not just for PHP annotation systems.



Regards //Björn Larsson




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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/10/2016 11:48 PM, Benjamin Eberlei wrote:



On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:


Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we
decided to live with doc-comments only.


one question, Rasmus Schultz post goes into the similar direction.

Any reason why the annotations are only a numeric list and not key 
value pairs? Key-Value would be much more powerful and address a ton 
of objections for us (Doctrine).
Attributes their selves are key-values, only nested values are numeric, 
but instead of simple values it's possible to use expression AST, that 
is more powerful than key-values.




In the current state it is pretty limited for more complex use-cases. 
I don't want to fully embrace the complexities that Larry showed for 
Drupal (in my opinion, too much annotations), but without key value 
pairs we could only use this when we nested JSON into the attribute 
value strings for example, not something I want to mix.


The Drupal example implementation on top of attributes is included in RFC.




Thanks. Dmitry.

[PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
it's not going to be the end of the world, if we decided to live with 
doc-comments only.


Thanks. Dmitry.

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Dmitry Stogov]

On 05/06/2016 05:06 AM, Jesse Schalken wrote:

If you're going to say "do what you want" with regards to annotations, then
just let them be a text string. Parsing the annotation as PHP but not
evaluating it as PHP seems a very strange and arbitrary half-way point. If
the thing consuming the AST is expected to eval() it, then why didn't PHP
do that already? If the thing consuming the AST is expected not to eval()
it, then it must effectively implement it's own language sharing PHP's
syntax but not PHP's semantics. Since it can't possibly attach meaning to
all of PHP's syntax, PHP will enforce that the string is valid PHP even
though the annotation language will be a very small subset. Not only does
that buy you very little in terms of validity checking, but it constrains
the annotation language to be a subset of PHP's syntax even when such a
constraint may be entirely inappropriate.

A true "do what you want" approach, if that is the right approach, would be
for the annotation body to be a free text string.


You talk about a subset of the proposed RFC.
It proposes an additional question about AST usage.

Thanks. Dmitry.



On Fri, May 6, 2016 at 8:36 AM, Dan Ackroyd  wrote:


On 5 May 2016 at 15:24, Larry Garfield  wrote:

because it doesn't define "right way".

Good.


I could easily see, for instance, Doctrine annotations building the
first, PHPUnit the second, and Zend the 3rd.

Good!

It's not the job of PHP core to tell people how to use annotations.
People can use them however they want.

If it turns out that there is a single 'right' way of using them,
everyone will gravitate to that way anyway.

If it turns out there are different 'right' ways of using them for
different use cases, people will be able to pick and choose the
use-case that is most appropriate.

And most importantly, if what people think is the 'right' way to use
them evolves over time, that can be accomplished completely in
user-land, without needing to update the internal implementation of
annotations.

cheers
Dan

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





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

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Dmitry Stogov]

On 05/05/2016 10:24 AM, Alexander Lisachenko wrote:

Hello, internals!


2016-05-05 9:48 GMT+03:00 Stanislav Malyshev >:


Maybe that's what we want to have here - freedom for everybody to
invent
their own languages - but I fear the danger of fragmentation here and
also people implementing tons of slightly different incompatible
parsers
for ASTs that are generated. We'd have Drupal attributes and Symphony
attributes and Doctrine attributes and Zend attributes and so on, and
each of them would have different semantics. Not sure this would be
good. But maybe it avoids arguing about the syntax now.


AST for attributes is a nice thing for abstracting from the concrete 
details about how attribute is handling by the concrete 
implementation. I can see a lot of common with class autoloading - 
earlier there were a lot of custom loaders, thanks to 
spl_autoload_register() that defines a stack of callbacks responsible 
for loading classes by their names. And everyone uses custom class 
loader, but later PSR-0 and PSR-4 were described and adopted in 
composer, so now we have one general tool for that. What if we select 
the same direction with the stack of callback?


How it should work: PHP engine stores all attributes in the plain AST 
without any transformations. This data should be accessible via 
ReflectionXXX->getAttributes(ReflectionAttribute::RETURN_AST). After 
that userland library can register a hook as attribute loader: e.g 
ReflectionAttribute::registerProcessor(SomeHandler::class, $isPrepend 
= true) or spl_attribute_handler_register(SomeProcessor::class, 
$isPrepend = true)


Each processor is a class with two methods:

interface AttributeProcessorInterface {
public function supports(Php\Ast\Node $attributeNode) : boolean;
/** @return mixed */
public function process(Php\Ast\Node $attributeNode);
}

After that if we call 
ReflectionXXX->getAttributes(ReflectionAttribute::RETURN_VALUE) PHP 
engine will call each processor and asks it if it supports this AST 
node. If processor supports this node, then engine call it's 
process($attributeNode) method, returning the result as a result, 
otherwise looks for another processor. If no processors can handle 
this AST then PHP can throw an exception about with information about 
missing processors for attributes.


I think this way can give a good start point with possibility to 
standardize handling of attributes in the future. From the PHP engine 
side, all attributes are AST nodes that can be processed later on the 
userland side.


Something like this may be implemented, but it should be well designed 
and approved first.
I'm not sure if this functionality should be especially implemented as 
part of Reflection API (this is easily implementable in PHP itself).
But in any case, this requires the base attribute functionality proposed 
in RFC (or some other).


Thanks. Dmitry.

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Dmitry Stogov]

On 05/05/2016 09:48 AM, Stanislav Malyshev wrote:

Hi!


It's also possible to write:

<>


you don't need to split your annotation into many attributes. You should
just adopt its syntax to become a valid PHP expression.
This expression is not going to be evaluated. It's going to be just
parsed into AST. and then you may traverse this AST and transform it
into other data structures.
The key idea of RFC was not to invite another language for meta-data,
but use PHP language itself.

This is a good way to avoid handling a lot of issue, but what I am
afraid of is that with this solution, what would happen that people
start doing exactly that - inventing another languages for metadata. In
fact, that's exactly what the expression above does - it uses "=" as
named argument,

ops, "=" actually should be replaced with "=>", or this won't work.


  and uses @ as special tag, not like PHP does. So it's in
fact mini-language using PHP's AST parser to tokenize its grammar, but
having separate semantics.
right. RFC doesn't propose any semantic, but higher layer may define 
completely different semantic.




Maybe that's what we want to have here - freedom for everybody to invent
their own languages - but I fear the danger of fragmentation here and
also people implementing tons of slightly different incompatible parsers
for ASTs that are generated. We'd have Drupal attributes and Symphony
attributes and Doctrine attributes and Zend attributes and so on, and
each of them would have different semantics. Not sure this would be
good. But maybe it avoids arguing about the syntax now.

Today, we have the same with doc-comments.
Attributes eliminate the need for separate parser and perform syntax 
validation at compile time.
They also provide flexible syntax to support all existing annotation 
systems, but they can't solve semantic problems, because they are just 
meta-data.


Thanks. Dmitry.




we don't have fully constructed classes at compile time. Classes may be
used during transformation from plain arrays and AST into application
specific data structures.

We don't have classes but we do namespace resolution right? For
namespace resolution, you don't need to have the class actually present.
I don't think we need it for ::class either.




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

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Dmitry Stogov]

On 05/01/2016 10:47 PM, Larry Garfield wrote:

On 04/30/2016 06:21 PM, Rowan Collins wrote:

On 30/04/2016 23:45, Stanislav Malyshev wrote:

Oh, of course you can have methods, but then it is strange conceptually
- you have a normal class, which some other part of the language just
uses for something else that classes are not routinely used for. I.e.,
does it call a constructor? When? With which arguments? What if it
fails? What if I just create an object of this class - would it be the
same as annotation object?


Hm... I was going to say "well, PDO does this if you use 
PDOStatement::fetchObject"; but then I remembered that the 
integration with the object there IS a bit weird - it injects raw 
properties, and *then* calls the constructor.


So, I'm not sure there's a limitation in terms of the object being 
data-only per se, but there are certainly oddities to be dealt with 
in terms of construction. And as you mentioned, mutability leads to 
another set of oddities - are the mutations stored for next time you 
request that annotation, or is the object recreated on each access?


Regards,


It would never occur to me to not have it regenerated on each access.  
If I want to cache it I will do so myself, thanks. :-)


However, that is not an issue created by using a defined structure for 
the annotation result.  The RFC currently says it returns an 
associative array, aka anonymous struct.  Those are always highly mutable.


The RFC proposes only Reflection*::getAttributres() that returns by value.
You may modify the returned copy, but the original attributes are immutable.

Thanks. Dmitry.


A classed object is as mutable as its design allows it to be.  To wit:

<<__Annotation>>
class Definition {
  protected $foo;
  protected $bar;
  public function getFoo() {}
  public function getBar() {}
}

< 1, bar => 2)>>
class Meep {}

The resulting annotation object would be an instance of Definition, 
which is for practical purposes immutable.  If it were returned as an 
array ['foo' => 1, 'bar' => 2], that would obviously be mutable.


Whether Definition should have mutator methods on it then becomes the 
implementer's decision, which is probably for the best.


--Larry Garfield




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

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Dmitry Stogov]

On 04/30/2016 02:47 AM, Larry Garfield wrote:
Most of the examples that have been given so far are either trivial 
boolean flags or data validation rules to be evaled.  In practice, 
very little of Drupal's use of annotations in Drupal 8 fit either 
category.  Rather, they're used primarily as, in essence, a serialized 
metadata object describing a class, which is used for registering that 
class and potentially others.  I figured I'd give the proposed syntax 
a try with some Drupal examples and see how well it fit.


Disclaimer: I'm sure someone will pipe up with "your use case is 
invalid because you shouldn't be using annotations that way."  I will 
be the first to agree that Drupal loves to take everything it does to 
an extreme, and some things may be better done other ways. However, 
these are still real-world use cases (currently built with Doctrine 
Annotations) that people are going to want to try and reimplement 
eventually using a core language feature.  This much data is put in 
one place primarily for DX reasons, to give developers a one-stop-shop 
for defining a given extension.  Saying "well just abandon your 
approach entirely" is not a satisfying answer.


Summary: It doesn't fit well at all, and there's features missing that 
would prevent Drupal from being able to use the proposed attributes 
RFC as-is, even without talking about classes-as-annotations.  A 
series of improvement request/suggestions are listed at the end of 
this email.


Simple example:

Drupal plugins (usually) use annotations.  Here's a simple example:

/**
 * Provides a block to display 'Site branding' elements.
 *
 * @Block(
 *   id = "system_branding_block",
 *   admin_label = @Translation("Site branding")
 * )
 */
class SystemBrandingBlock {

}

This defines a "block" (type of plugin).  It's unique machine name 
identifier is "system_branding_block", and its human-facing label is 
"Site branding", which is marked as a translatable string. That all 
seems reasonable to include here.


Here's what I came up with for a possible attributes version:

<>
<>
<>
class SystemBrandingBlock {

}

Not too bad at first blush, but there's 2 problems.

It's also possible to write:

<>

Then you'll need you own layer that translates "Drupal" attributes from 
AST to everything you like.




1) There's no indication that the label is a translatable string. One 
could hard-code that logic into whatever processing happens for 
PluginAdminLabel, but then there's no indication for our gettext 
scanner that "Site branding" is translatable and should be extracted 
for translation.


2) If we want to say that the value "Block" corresponds to a class 
(something that would be up to the parser to do), there's no 
indication of the namespace against which to resolve "Block".  The 
alternative would be to require including the full class name string, 
like so:


<>

But that DX is quite terrible.  We introduced ::class in 5.5 for a 
reason.  Better would be:


<>

But that works only if the attribute parser resolves Block::class 
against the currently "use"d namespaces so that it's a full class name 
string when reflection picks it up.  If not, then that means the 
user-space parser needs to catch that, then go back to the file and 
figure out the available use statements and resolve against those.  
It's doable, but ugly and certainly more work than I'd want to put in 
as someone writing such a parser.


I don't know if that's a feature of the patch at the moment, but it 
would need to be.


So even in a simple case we have insufficient functionality.

Complex example:

OK, let's go to the other end and look at an example that is way more 
complicated.  (Yes, maybe too complicated.)  Doctrine annotations are 
also used to define Entity Types, which correspond to a class.  Here's 
the annotation for a Node, in all its glory:


/**
 * Defines the node entity class.
 *
 * @ContentEntityType(
 *   id = "node",
 *   label = @Translation("Content"),
 *   bundle_label = @Translation("Content type"),
 *   handlers = {
 * "storage" = "Drupal\node\NodeStorage",
 * "storage_schema" = "Drupal\node\NodeStorageSchema",
 * "view_builder" = "Drupal\node\NodeViewBuilder",
 * "access" = "Drupal\node\NodeAccessControlHandler",
 * "views_data" = "Drupal\node\NodeViewsData",
 * "form" = {
 *   "default" = "Drupal\node\NodeForm",
 *   "delete" = "Drupal\node\Form\NodeDeleteForm",
 *   "edit" = "Drupal\node\NodeForm"
 * },
 * "route_provider" = {
 *   "html" = "Drupal\node\Entity\NodeRouteProvider",
 * },
 * "list_builder" = "Drupal\node\NodeListBuilder",
 * "translation" = "Drupal\node\NodeTranslationHandler"
 *   },
 *   

Re: [PHP-DEV] zend_pass_function/zif_pass

[Dmitry Stogov]

I don't see a big problem exporting zif_pass, if this's really necessary.


Thanks. Dmitry.


From: Nikita Popov <nikita@gmail.com>
Sent: Saturday, April 30, 2016 8:40:54 PM
To: Derick Rethans
Cc: Dmitry Stogov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] zend_pass_function/zif_pass

On Sat, Apr 30, 2016 at 7:12 PM, Derick Rethans 
<der...@php.net<mailto:der...@php.net>> wrote:
Hi!

I'm trying to make Xdebug up to date with master again, and after fixing
the static changes that Dmitry highlighted, I am still baffled by
something else.

My function traces now have an extra entry for each constructor - even
for classes that have no constructor, such as stdClass.

Code



In PHP 7.1 (master) this generates:

   => $tf = '/tmp/xdt5724dfa31b3050.51884776.xt' 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
0.0017 386376 -> {main}() 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:0
   => $a = class stdClass {  } 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
0.0017 386472 -> xdebug_stop_trace() 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
0.0018 386568

Where as in PHP 5.6 and 7.0, it generates:

TRACE START [2016-04-30 17:10:19]
   => $tf = '/tmp/xdt5724e6fb674b31.38510038.xt' 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
   => $a = class stdClass {  } 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
0.0006 274008 -> xdebug_stop_trace() 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
0.0006 274128
TRACE END   [2016-04-30 17:10:19]

The master version has the extra {main}, which comes from an additional
call to zend_execute_internal.

When looking into this, I see that that extra frame is a handle
zend_pass_function / zif_pass. How has this changed recently, and more
importantly, how can I detect this? I can't do "edata.func ==
zend_pass_function" as neither zend_pass_function or zif_pass are
exported symbols.

Any hints on how to handle this?

cheers,
Derick

Hey Derick!

This change is due to http://www.serverphorums.com/read.php?7,1439618,1439618 / 
https://github.com/php/php-src/commit/8e5b139732893d2a5f6ba3ae0a0b2b5cf6dba09f.

I don't see a good way for you to handle this as things stand now. I think we 
should export the zend_pass_function symbol.

Nikita

Re: [PHP-DEV] Forbid dynamic calls to scope introspection/modification functions

[Dmitry Stogov]

Hi Nikita,

We already discussed this, and I told that I don't have strong opinion about 
this change.
>From one pint of view, your are going to disable some legal code patterns.

function foo() {
  $f = "func_num_args";
  $n = $f();
}

array_map("export", [$_GET, $_POST]);

On the other hand, it's better to fix this problem once and forever (in 7.1 
release).

I think it's better to keep this email as RFC, at least for documentation of BC 
break purpose.
I'm not sure if we need 2 week discussion + 2 weeks voting for this.
I think 1 week voting should be enough?
and I'm sure, it should pass.

Thanks. Dmitry.




From: Nikita Popov 
Sent: Friday, April 29, 2016 12:48:48 PM
To: PHP internals
Subject: [PHP-DEV] Forbid dynamic calls to scope introspection/modification 
functions

Hi internals!

Welcome to another edition of "crazy PHP edge-cases you don't want to know
about".

I'd like to introduce a restriction that forbids performing dynamic calls
to scope introspection and modification functions. "Dynamic calls" here
means things like $fn(), call_user_func($fn) and array_map($fn, ...).
"Scope introspection functions" refers to the following functions that in
one way or another inspect or modify parent stack frames:

 * extract()
 * compact()
 * get_defined_vars()
 * parse_str() with one arg
 * mb_parse_str() with one arg
 * func_get_args()
 * func_get_arg()
 * func_num_args()

I'd like to introduce this restriction for a number of reasons, which will
be outlined in the following. There are essentially two core problems: A)
It is not clear how these functions should behave in this situation --
indeed I will show examples of behavior differing due to inconsequential
changes, differing between different PHP runtimes or versions and just
generally behaving crazily. B) These calls pose a stability problem (yay
segfaults) and violate assumptions of existing optimizations (yay more
segfaults).

A) The primary issue is that dynamic calls to these functions have unclear
behavior and may lead to some very odd behavior. They all fundamentally
work by inspecting higher stack frames, but don't agree on which frame they
should operate on.

Example #1:

namespace {
function test($a, $b, $c) {
var_dump(call_user_func('func_num_args'));
}
test(1, 2, 3);
}

namespace Foo {
function test($a, $b, $c) {
var_dump(call_user_func('func_num_args'));
}
test(1, 2, 3);
}

This code will print int(3) int(1) on PHP 7 and HHVM (and two times int(1)
on PHP 5). The reason is that in the non-namespaced case the number of
arguments of the test() frame is returned, while in the namespaced case the
number of arguments of the call_user_func() frame is returned, because of
internal differences in stack frame management.

Example #2:

function test() {
array_map('extract', [['a' => 42]]);
var_dump($a);
}
test();

This will print int(42) on PHP 5+7, but result in an undefined variable on
HHVM. The reason is that HHVM will extract ['a' => 42] into the scope of
the array_map() frame, rather than the test() frame. It does this because
HHVM implements array_map as a userland (HHAS) function, rather than an
internal function.

One might write this off as a bug in the HHVM implementation, but really
this illustrates a dichotomy between internal and userland functions with
regard to dynamic calls of these functions. Namely, if you were to
reimplement the array_map function in userland

function array_map($fn, $array) {
$result = [];
foreach ($array as $k => $v) {
$result[$k] = $fn($v);
}
return $result;
}

and then try the same snippet as Example #2, it would indeed extract the
array into the scope of array_map() and not the calling test() function. I
hope this helps to further illustrate why calling these functions
dynamically is a problem: They will generally be executed in a different
scope than the one where the callback is defined. This means you can
actually arbitrarily modify the scope of functions that accept callbacks,
even though they were certainly not designed for this use. E.g. you can
switch the $fn callback in the middle of the array_map execution using
something like:

array_map('extract', [['fn' => ...]]);

Just imagine the possibilities of this newly discovered feature! But this
is only where it starts. PHP has a number of magic callbacks that may be
implicitly executed in all kinds of contexts. For example, what happens if
we use one of these in spl_autoload_register?

Example #3:

spl_autoload_register('parse_str');
function test() {
$FooBar = 1;
class_exists('FooBar');
var_dump($FooBar); // string(0) ""
}
test();

Now any invocation of the autoloader (here using class_exists, but can be
generalized to new or anything else) will create a variable for the class
name in the local scope (with value ""). Of course there's more fun to be
had here (tick functions!), but let's leave it at that and 

[PHP-DEV] Re: New HashTable implementation?

[Dmitry Stogov]

Hi Matt,

I also tried different hash functions (including mumur3) and came to similar 
result.
Faster function but more hash collisions.
Actually these collisions occurs not because of different hash values, but 
because of small hash array size.
Also the way we transform hash value into hash array index (use low bits) also 
may matter.
If we decrease hash load-factor, we get less collisions, but use more memory 
and this also leads to cache misses increase.

You are welcome to try Robin-Hood, in case you get positive results we may 
switch to it (however I'm sceptical)

Thanks. Dmitry.


From: Matt Wilmas <php_li...@realplain.com>
Sent: Friday, April 29, 2016 3:04:44 AM
To: internals@lists.php.net
Cc: Dmitry Stogov; Nikita Popov; Xinchen Hui
Subject: New HashTable implementation?

Hi all,

Last June, it was briefly mentioned about changing PHP's string hash
function [1] (DJB33 *seems* pretty horrible, after all, as far as
collisions...).  So 8 months ago I tried almost, if not, a half-dozen of
them (including Murmur3) that were simple enough to quickly toss in.

The result?  In all cases, I believe, fewer instructions (in zend_hash_find,
and the hashing function), BUT also a slight-to-small increase in cache
misses in Wordpress and other scripts...

And in a test filling an array with a million "string_$i" keys (high
collision pattern for DJB33?), the speed was halved by the *huge* cache miss
increase. :-/

I couldn't quite understand what was happening, where, if there were fewer
collisions...  Misses all spread out in the hash-array?

So there didn't seem to be anything useful to gain there.


Now, after seeing Bogdan's hash optimization idea last month [2], and
reading Nikita's blog post again, I had some ideas I'd like to try --
assuming nobody else is planning major changes. :-)  Besides Nikita, I'm
addressing Dmitry and Xinchen because your names are on some minor hash
items on the 7.1 ideas wiki [4].

I'm thinking of a Robin Hood implementation with Universal hashing [5] (of
int keys and the string hashes).  I haven't touched any code yet, but think
I've worked out all the details in my head, and am ready to take a stab at
it.  I think it's fairly simple to get the basics working; and when I see
how that goes, I can do the additional optimizations I have in mind that it
allows (including reduced memory, on 64-bit at least).

Question: Can I use zval.u1.v.reserved ?  I guess I'll find out otherwise.
:-O


The string hash function itself is really a separate thing [6], but fasthash
[7] (not to be confused with "superfast") looks like a good one that I
missed before...  After thinking about things, I think we could even
keep/use a 64-bit hash on 32-bit arch.


Well, just wanted to mention it first if anyone has a comment. :-)  Should
be interesting, but no idea how it'll perform (lookups should be very, very
fast (upsizing also); but cache factors and inserts/deletes are wildcards).
Wish me luck!?


Thanks,
Matt

[1] https://marc.info/?l=php-internals=143444845304138=2
[2] https://marc.info/?t=14574424811=1=2
[4] https://wiki.php.net/php-7.1-ideas
[5] https://en.wikipedia.org/wiki/Universal_hashing
[6] https://github.com/rurban/smhasher
[7] https://github.com/rurban/smhasher/blob/master/doc/fasthash64


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

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

More or less right. It's easy to archive the "right" goal, if you own the both 
football teams.


From: Tom Worster <f...@thefsb.org>
Sent: Thursday, April 28, 2016 11:40:53 PM
To: Levi Morrison; Dmitry Stogov
Cc: internals
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

Levi,

>From one reasonable point of view, Union and Nullable are in conflict with
each other. If one prefers Union then one might argue in favor of Union
over related but different proposals. When it comes to the vote, it's
difficult to support both except with the argument that "I can settle for
Nullable if Union doesn't pass vote", which, when you think about it, is
not really supporting both.

If Union goes to vote before anything else, voters will to take into
account what they expect to subsequently go to vote. So your stance
relative to that matters. Hence it's not really clear what you want while
you continue to own both.

This is how I understand Dmitry's concerns (correct me if I'm wrong,
Dmitry).

It would be easier to understand if you would *either* abandon Union (for
7.1) and throw your support behind Nullable *or* disown Nullable, let
Dmitry champion it, and the two RFCs to vote as alternatives.

I understand that you see Union as a kind of superset of Nullable (correct
me if I'm wrong) but when it comes to the voting, there's no fair way to
organize that. Someone's going to be unhappy.

Tom


On 4/28/16, 3:16 PM, "Dmitry Stogov" <dmi...@zend.com> wrote:

>Levi, I provided an implementation for your RFC on February 2015, and I
>would be glad if your RFC was accepted that time.
>Bit since that time you block it in respect to "Union Types"
>
>See conversation at PR https://github.com/php/php-src/pull/1045
>
>I would be also glad if your "Nullable Types" RFC was accepted now, but I
>don't trust in your intention to support it.
>
>
>From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi
>Morrison <le...@php.net>
>Sent: Thursday, April 28, 2016 10:02:20 PM
>To: Dmitry Stogov
>Cc: Joe Watkins; internals; Tom Worster
>Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types
>for only return values
>
>On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>> Levi, I don't understand, why do you keep trying to own "Nullable
>>Types" RFC, if you like completely different "Union Types".
>
>I don't understand; I wrote the RFC. What do you mean, "keep trying to
>own" it? I wrote both Nullable Types and Union Types. Some view those
>RFC's as competing, but they can also be orthogonal. I see the value
>in having both.



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

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Levi, I provided an implementation for your RFC on February 2015, and I would 
be glad if your RFC was accepted that time.
Bit since that time you block it in respect to "Union Types"

See conversation at PR https://github.com/php/php-src/pull/1045

I would be also glad if your "Nullable Types" RFC was accepted now, but I don't 
trust in your intention to support it.


From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
Morrison <le...@php.net>
Sent: Thursday, April 28, 2016 10:02:20 PM
To: Dmitry Stogov
Cc: Joe Watkins; internals; Tom Worster
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov <dmi...@zend.com> wrote:
> Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, 
> if you like completely different "Union Types".

I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

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

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, 
if you like completely different "Union Types".


From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
Morrison <le...@php.net>
Sent: Thursday, April 28, 2016 9:47:18 PM
To: Joe Watkins
Cc: Dmitry Stogov; internals; Tom Worster
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins <pthre...@pthreads.org> wrote:
> Levi,
>
> Why do you need to block Dmitry's return type nullable RFC ?
>
> We need to move forward, that has an implementation, ready for a long
> time, doesn't seem to block nullable parameter types rfc, either separately
> or as part of unions.
>
> So, I'm not understanding why you need to hold up Dmitry any more.
>
> Please, explain.
>
> Cheers
> Joe
>
> On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison <le...@php.net> wrote:
>>
>> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>> > your Nullable RFC doesn't propose working implementation.
>> >
>> > 
>> > From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of
>> > Levi Morrison <le...@php.net>
>> > Sent: Thursday, April 28, 2016 8:39:03 PM
>> > To: Dmitry Stogov
>> > Cc: internals; Tom Worster
>> > Subject: Re: Request to withdraw RFC's for nullable types for only
>> > return values
>> >
>> > On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>> >> Thanks for catching the BC break.
>> >> Fortunately, we didn't release 7.0.6 with this problem.
>> >>
>> >> I see some sense in introducing that check, but changing behaviour
>> >> requires RFC and definitely not allowed in minor versions.
>> >>
>> >> I'm not going to withdraw
>> >> https://wiki.php.net/rfc/nullable_return_types
>> >> It doesn't prohibit usage of nullable for arguments, and even sets
>> >> additional question.
>> >
>> > In that case: are you fine with my RFCs going to vote first (and
>> > soon)? We presently have four somewhat competing RFCs and need to work
>> > out voting order.
>> >
>> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>>
>> It doesn't have an implementation, sure. But you already worked out
>> return types, the basics are already there in parameter types and
>> there's an implementation in HHVM. Do you really think this would be a
>> blocker? There is no reason to believe that a short-hand nullable
>> types implementation cannot be reasonably done.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort
of political campaign. Let me try to straighten this:

As evidenced by this bug report that needs a fix there is a need for
nullable parameter types that is not tied to a default of null.
Dmitry's RFC does not handle this. Nor does Tom's.

There is an RFC that can solve both return types and parameter types.
I'm asking them to withdraw because they don't meet those needs and
there is an RFC that does. It just so happens to be mine. It also
happens to be the first drafted RFC.

This is not an unreasonable request. In fact, it's the much nicer
option that just opening vote on mine first without talking about it
on list at all. And lastly, it's just a request. They don't have to
withdraw.

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

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

PHP method compatibility rules didn't take into account default values of 
arguments.
Adding new rule is not just a bug fix, and breaks existing code.


From: Bob Weinand <bobw...@hotmail.com>
Sent: Thursday, April 28, 2016 9:12:54 PM
To: Dmitry Stogov
Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only 
return values

Yeah,
It's a BC break; hence I've accepted it being reverted from 7.0.
I've only put the fix back in 7.1 thus.

Or is it your opinion that we shall hold a formal RFC vote for a glaring bug? 
That sounds pretty much like a waste of everyones time to me. RFC votes IMO are 
for cases where we don't have clear consensus. Or is really anyone disputing 
this fix?

Bob Weinand (iPhone)

> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov <dmi...@zend.com>:
>
> This is a "fix", that introduces BC break.
> Even if I see a reason in this check, it's still a break.
> If you remember, we voted for almost for every BC break during PHP-7.0 
> development.
>
>
> 
> From: Bob Weinand <bobw...@hotmail.com>
> Sent: Thursday, April 28, 2016 8:36:22 PM
> To: Dmitry Stogov
> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
> Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only 
> return values
>
>> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmi...@zend.com>:
>>
>> Hi,
>>
>> The BC break in PHP-7.0 was introduced by commit 
>> ee9a78a033696ff9546fb1dbfecd28f20477b511
>>
>> Author: Joe Watkins <krak...@php.net>
>> Date:   Mon Mar 28 11:54:25 2016 +0100
>>
>> Late, there were few more commits that changed and moved the problematic 
>> code.
>>
>> Anatol, I think we should revert this before 7.0.6 release.
>>
>> Thanks. Dmitry.
>>
>> ________
>> From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
>> Morrison <le...@php.net>
>> Sent: Thursday, April 28, 2016 18:40
>> To: internals
>> Cc: Dmitry Stogov; Tom Worster
>> Subject: Request to withdraw RFC's for nullable types for only return values
>>
>> I have discovered through a [bug report][1] a case where having
>> explicitly nullable parameters would be of value.
>>
>> >
>> interface Foo {
>>   public function bar(array $baz = null);
>> }
>>
>> class Hello implements Foo {
>>   public function bar(array $baz = array())  {}
>> }
>>
>> ?>
>>
>> You can theoretically change the default value in a sub-type, but in
>> this case moving away from the default value of null breaks because
>> the subtype no longer permits null. It is important to realize that we
>> previously *allowed* this behavior since PHP 5.1 but was fixed in
>> 7.0.6.
>>
>> If instead we had nullable types separately from default values of
>> null this could change to:
>>
>> >
>> class Hello implements Foo {
>>   public function bar(array | null $baz = [])  {}
>> }
>>
>> ?>
>>
>> (or a short-form `?array $baz = []` if short-form passes)
>>
>> This preserves the ability to be null but changes the default value.
>> Of course, there may be other code changes necessary to future-proof
>> their code but there current code would now work without having to
>> rewrite any method bodies (just signatures).
>>
>> In light of this I kindly request that RFCs that add nullable types
>> for only return values be withdrawn. So that [Union Types][2] and
>> [Nullable Types][3] can go forward unhindered.
>>
>>
>> [1]: https://bugs.php.net/bug.php?id=72119
>> [2]: https://wiki.php.net/rfc/union_types
>> [2]: https://wiki.php.net/rfc/nullable_types
>
> Hey Dmitry,
>
> thanks for reverting… but
>
> I've seen you had merged just straight up?
> I assume this was unintentional (as it should definitely remain fixed in 7.1).
> Thus I've reverted your changes in master (only) and added an appropriate 
> NEWS entry there.
>
> Thanks,
> Bob

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

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

This is a "fix", that introduces BC break.
Even if I see a reason in this check, it's still a break.
If you remember, we voted for almost for every BC break during PHP-7.0 
development.



From: Bob Weinand <bobw...@hotmail.com>
Sent: Thursday, April 28, 2016 8:36:22 PM
To: Dmitry Stogov
Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only 
return values

> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmi...@zend.com>:
>
> Hi,
>
> The BC break in PHP-7.0 was introduced by commit 
> ee9a78a033696ff9546fb1dbfecd28f20477b511
>
> Author: Joe Watkins <krak...@php.net>
> Date:   Mon Mar 28 11:54:25 2016 +0100
>
> Late, there were few more commits that changed and moved the problematic code.
>
> Anatol, I think we should revert this before 7.0.6 release.
>
> Thanks. Dmitry.
>
> 
> From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
> Morrison <le...@php.net>
> Sent: Thursday, April 28, 2016 18:40
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: Request to withdraw RFC's for nullable types for only return values
>
> I have discovered through a [bug report][1] a case where having
> explicitly nullable parameters would be of value.
>
> 
> interface Foo {
>public function bar(array $baz = null);
> }
>
> class Hello implements Foo {
>public function bar(array $baz = array())  {}
> }
>
> ?>
>
> You can theoretically change the default value in a sub-type, but in
> this case moving away from the default value of null breaks because
> the subtype no longer permits null. It is important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
>
> If instead we had nullable types separately from default values of
> null this could change to:
>
> 
> class Hello implements Foo {
>public function bar(array | null $baz = [])  {}
> }
>
> ?>
>
> (or a short-form `?array $baz = []` if short-form passes)
>
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
>
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
>
>
>  [1]: https://bugs.php.net/bug.php?id=72119
>  [2]: https://wiki.php.net/rfc/union_types
>  [2]: https://wiki.php.net/rfc/nullable_types

Hey Dmitry,

thanks for reverting… but

I've seen you had merged just straight up?
I assume this was unintentional (as it should definitely remain fixed in 7.1).
Thus I've reverted your changes in master (only) and added an appropriate NEWS 
entry there.

Thanks,
Bob

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

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

I'm not happy with the fact, that you propose two competing RFCs, support only 
one and trying to withdraw other competitors.


From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
Morrison <le...@php.net>
Sent: Thursday, April 28, 2016 8:47:41 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> your Nullable RFC doesn't propose working implementation.
>
> 
> From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
> Morrison <le...@php.net>
> Sent: Thursday, April 28, 2016 8:39:03 PM
> To: Dmitry Stogov
> Cc: internals; Tom Worster
> Subject: Re: Request to withdraw RFC's for nullable types for only return 
> values
>
> On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>> Thanks for catching the BC break.
>> Fortunately, we didn't release 7.0.6 with this problem.
>>
>> I see some sense in introducing that check, but changing behaviour requires 
>> RFC and definitely not allowed in minor versions.
>>
>> I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
>> It doesn't prohibit usage of nullable for arguments, and even sets 
>> additional question.
>
> In that case: are you fine with my RFCs going to vote first (and
> soon)? We presently have four somewhat competing RFCs and need to work
> out voting order.
>
> Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

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

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

all these are good points not to commit BC breaks in hurry.


From: Joe Watkins <pthre...@pthreads.org>
Sent: Thursday, April 28, 2016 8:41:34 PM
To: Bob Weinand
Cc: Dmitry Stogov; Anatol Belski; internals; Levi Morrison
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only 
return values

The problem is as Levi explained though Bob, don't we actually require 
nullables/unions for that case ?

Maybe we can move forward now, confident that by the time 7.1 is released we 
will have one of those things ?

The problems with that are, the RFC's for unions/intersections don't match the 
implementation, and none of us have a good idea how to implement the RFCs.

In addition, nobody can agree which nullable types RFC should go to vote, or 
how the whole nullable type question should be resolved.

Cheers
Joe


On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand 
<bobw...@hotmail.com<mailto:bobw...@hotmail.com>> wrote:

> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov 
> <dmi...@zend.com<mailto:dmi...@zend.com>>:
>
> Hi,
>
> The BC break in PHP-7.0 was introduced by commit 
> ee9a78a033696ff9546fb1dbfecd28f20477b511
>
> Author: Joe Watkins <krak...@php.net<mailto:krak...@php.net>>
> Date:   Mon Mar 28 11:54:25 2016 +0100
>
> Late, there were few more commits that changed and moved the problematic code.
>
> Anatol, I think we should revert this before 7.0.6 release.
>
> Thanks. Dmitry.
>
> 
> From: morrison.l...@gmail.com<mailto:morrison.l...@gmail.com> 
> <morrison.l...@gmail.com<mailto:morrison.l...@gmail.com>> on behalf of Levi 
> Morrison <le...@php.net<mailto:le...@php.net>>
> Sent: Thursday, April 28, 2016 18:40
> To: internals
> Cc: Dmitry Stogov; Tom Worster
> Subject: Request to withdraw RFC's for nullable types for only return values
>
> I have discovered through a [bug report][1] a case where having
> explicitly nullable parameters would be of value.
>
> 
> interface Foo {
>public function bar(array $baz = null);
> }
>
> class Hello implements Foo {
>public function bar(array $baz = array())  {}
> }
>
> ?>
>
> You can theoretically change the default value in a sub-type, but in
> this case moving away from the default value of null breaks because
> the subtype no longer permits null. It is important to realize that we
> previously *allowed* this behavior since PHP 5.1 but was fixed in
> 7.0.6.
>
> If instead we had nullable types separately from default values of
> null this could change to:
>
> 
> class Hello implements Foo {
>public function bar(array | null $baz = [])  {}
> }
>
> ?>
>
> (or a short-form `?array $baz = []` if short-form passes)
>
> This preserves the ability to be null but changes the default value.
> Of course, there may be other code changes necessary to future-proof
> their code but there current code would now work without having to
> rewrite any method bodies (just signatures).
>
> In light of this I kindly request that RFCs that add nullable types
> for only return values be withdrawn. So that [Union Types][2] and
> [Nullable Types][3] can go forward unhindered.
>
>
>  [1]: https://bugs.php.net/bug.php?id=72119
>  [2]: https://wiki.php.net/rfc/union_types
>  [2]: https://wiki.php.net/rfc/nullable_types

Hey Dmitry,

thanks for reverting... but

I've seen you had merged just straight up?
I assume this was unintentional (as it should definitely remain fixed in 7.1).
Thus I've reverted your changes in master (only) and added an appropriate NEWS 
entry there.

Thanks,
Bob

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

your Nullable RFC doesn't propose working implementation.


From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
Morrison <le...@php.net>
Sent: Thursday, April 28, 2016 8:39:03 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> Thanks for catching the BC break.
> Fortunately, we didn't release 7.0.6 with this problem.
>
> I see some sense in introducing that check, but changing behaviour requires 
> RFC and definitely not allowed in minor versions.
>
> I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
> It doesn't prohibit usage of nullable for arguments, and even sets additional 
> question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

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

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

hi Joe,


No problem, great it's fixed before 7.0.6 release.

I think this change might be introduced only together with nullable or union 
types.

Otherwise it makes a problem, described by Levi, that doesn't allow running the 
same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.


Thanks. Dmitry.



From: Joe Watkins <pthre...@pthreads.org>
Sent: Thursday, April 28, 2016 8:20:12 PM
To: Dmitry Stogov
Cc: Levi Morrison; internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

Evening Dmitry,

This was discussed at length with bob, and I think nikita also, it seemed like 
a bug fix rather than a feature.

Happy for it to be moved into 7.1 ... sorry for dropping the ball there ...

Cheers
Joe

On Thu, Apr 28, 2016 at 6:07 PM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:
Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires RFC 
and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets additional 
question.

Thanks. Dmitry.


From: morrison.l...@gmail.com<mailto:morrison.l...@gmail.com> 
<morrison.l...@gmail.com<mailto:morrison.l...@gmail.com>> on behalf of Levi 
Morrison <le...@php.net<mailto:le...@php.net>>
Sent: Thursday, April 28, 2016 6:40:59 PM
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: Request to withdraw RFC's for nullable types for only return values

I have discovered through a [bug report][1] a case where having
explicitly nullable parameters would be of value.



You can theoretically change the default value in a sub-type, but in
this case moving away from the default value of null breaks because
the subtype no longer permits null. It is important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires RFC 
and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets additional 
question.

Thanks. Dmitry.


From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
Morrison <le...@php.net>
Sent: Thursday, April 28, 2016 6:40:59 PM
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: Request to withdraw RFC's for nullable types for only return values

I have discovered through a [bug report][1] a case where having
explicitly nullable parameters would be of value.



You can theoretically change the default value in a sub-type, but in
this case moving away from the default value of null breaks because
the subtype no longer permits null. It is important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

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

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Hi,

The BC break in PHP-7.0 was introduced by commit 
ee9a78a033696ff9546fb1dbfecd28f20477b511 

Author: Joe Watkins <krak...@php.net>
Date:   Mon Mar 28 11:54:25 2016 +0100

Late, there were few more commits that changed and moved the problematic code.

Anatol, I think we should revert this before 7.0.6 release.

Thanks. Dmitry.


From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi 
Morrison <le...@php.net>
Sent: Thursday, April 28, 2016 18:40
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: Request to withdraw RFC's for nullable types for only return values

I have discovered through a [bug report][1] a case where having
explicitly nullable parameters would be of value.



You can theoretically change the default value in a sub-type, but in
this case moving away from the default value of null breaks because
the subtype no longer permits null. It is important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.

If instead we had nullable types separately from default values of
null this could change to:



(or a short-form `?array $baz = []` if short-form passes)

This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).

In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.


  [1]: https://bugs.php.net/bug.php?id=72119
  [2]: https://wiki.php.net/rfc/union_types
  [2]: https://wiki.php.net/rfc/nullable_types

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

[PHP-DEV] Re: Request for Karma

[Dmitry Stogov]

Hi Richard,

I already got help from Pierrick. He is the author of previous RFC 
https://wiki.php.net/rfc/annotations
sorry, I have no idea who can give the karma.

Thanks. Dmitry.


From: Fleshgrinder <p...@fleshgrinder.com>
Sent: Wednesday, April 27, 2016 20:34
To: php-internals
Cc: Dmitry Stogov
Subject: Request for Karma

Hello fellows!

I would like to request karma for the PHP wiki to support others in
writing RFCs and maybe some time in the future contribute RFCs. For now
I plan to help Dmitry Stogov as co-author with the already existing
Attributes RFC.

A few words about my person might not hurt I guess. I am an MSc and PHP
developer from Austria. I work with PHP since many years, however, I am
also fluent in Java, JavaScript, Shell, ... and know my ways around in
C, C++, Rust, ... I am currently working at trivago in Germany as lead
PHP developer of a small development team.

I already registered a wiki account under the name "fleshgrinder".
--
Richard "Fleshgrinder" Fussenegger


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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/27/2016 08:25 AM, Pierrick Charron wrote:

Hi all,

First of all thanks dmitry for your great work and for bringing the 
RFC back to life.


I think it would be great to allow users to define their own 
annotations and give them some structure (what the annotation is made 
of). For example let's say I apply an annotation to define that a 
property is a string with a length. In the proposed RFC I will have 
something like this :


class Foo {
<>
public string $bar;
}

But how could i know for example that StringLength can take an extra 
parameters I would have to read the code of the annotation framework 
see how it parse, use it etc... But if I can define the structure 
(this is a quickly invented pseudo syntax and I'm not proposing it)


annotation MyAnnotation\StringLength {
private int $length;
private string $comment = "Default value";
}

With this definition I know that the Annotation take 2 parameters one 
int and one string, that the comment has a default value and can be 
omitted etc...


Also what I dislike about using a simple array with no definition is 
that you can't annotate an annotation since there is no definition. I 
know it can look complex but think about the power you can add to the 
system. It would help us solve some problems that could not be solved 
(or at least I can't see any way of doing it) if you can't have a 
definition you can't attach behaviour/metadata to it.


Here are some problems we could solve (those are just examples)

1. Are annotations inhereted or not ? Some will say yes, some now but 
I think they actually both make sense. For example we could imagine 
that if I annotate a method of my interface as deprecated I want it to 
be inhereted because all implementations are, but author annotation 
should not be inherited because I'm not necessarily the author of the 
implementation. So we could say that annotations are by default not 
inherited and we could have an <> annotation


<>
annotation deprecated {
}

annotation author {
public string $name;
public string $mail;
}

2. Is a specific kind of annotation applicable to only one kind of 
statement or multiple ? JIT don't make sense on a property...


<>
annotation jit {
}

3. Current version of the RFC propose that we could either have AST or 
to execute the AST but we could imagine to get both


annotation assert {
<>
public ast\node $node;
public string $message;
}

Again, this is just a couple of quick ideas, but this would make 
things less magic/obscure with a definition and far more flexible. If 
we agree that we want a definition we could work on how to create this 
definition (we could use some stuff from the old Annotations RFC 
https://wiki.php.net/rfc/annotations?rev=1302087566) to update this 
one with a new syntax or use interface as proposed in the first 
implementation


class Deprecated implements Annotation {
}

Maybe


didn't you think, that these annotation over-design made your RFC fail?

You can't create objects at compile-time, and should delay their 
creation until Reflection*::getAttributes().
Returning objects directly form Reflection*::getAttributes() doesn't 
improve flexibility at all.

This would just increase the complexity of the patch...

As I already said many times, all this extensions are possible to do in 
few PHP lines on top of base functionality.

See "Doctrine use-case" at https://wiki.php.net/rfc/attributes#use_cases

If you add these extensions directly into PHP implementation in C, 
you''ll have to support them, and you'll always miss some needs for 
"last use-case", but you won't able to change PHP behavior between major 
PHP versions.


Thanks. Dmitry.



Pierrick

[PHP-DEV] Re: Property Guards Optimization

[Dmitry Stogov]

great. thanks.



From: Nikita Popov <nikita@gmail.com>
Sent: Wednesday, April 27, 2016 00:15
To: Dmitry Stogov
Cc: internals
Subject: Re: Property Guards Optimization

On Tue, Apr 26, 2016 at 10:49 PM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:

Hi Nikita,


Could you please review the patch 
https://gist.github.com/dstogov/22813388180fd4c1d7b0ead35715b067


This is an implementation of your idea about specialized version for single 
active guard.

I hope, everything is fine, all tests are passed.

I don't see anything wrong with the patch.

Nikita

[PHP-DEV] Property Guards Optimization

[Dmitry Stogov]

Hi Nikita,


Could you please review the patch 
https://gist.github.com/dstogov/22813388180fd4c1d7b0ead35715b067


This is an implementation of your idea about specialized version for single 
active guard.

I hope, everything is fine, all tests are passed.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

Just because HHVM is closer to PHP than C#.



From: Dominic Grostate <codekest...@googlemail.com>
Sent: Tuesday, April 26, 2016 19:43
To: Dmitry Stogov
Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev
Subject: Re: [PHP-DEV] [RFC] PHP Attributes


Why not like C#?

[Description("My Function")]
function my_function()
{}

Without the semicolon, this wouldn't be valid in any other context.

On 26 Apr 2016 8:41 a.m., "Dmitry Stogov" 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:


On 04/25/2016 11:20 PM, Stanislav Malyshev wrote:
Hi!

No, but this is valid:

@atrr(); function foo() { ... }

That's perhaps a little too close for comfort...?
That's different syntax. If you put ; in the middle of statement, it can
change - "$c = $a + $b;" is not the same as "$c = $a; + $b;" - but
nobody thinks + can not be used because of that. As I said, << and >>
are existing operators too, so if you are creative enough, I'm sure you
can find cases like that too.

Hi Stas,

You may try to replace attribute syntax with @attr(...) (without semicolon) 
into our PHP parser.
Note that we have LALR grammar + restrictions caused by semantic actions.
If you are able to do this, I'll add it into the RFC as an option.

Thanks. Dmitry.


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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

"Foo | null" doesn't make sense without "Union Types".
Voting for one RFC first makes a preference and unfair.

Voting for two different RFCs with 2/3 majority is not good as well.
But this is the best option from my point, in case both pass we may make 
additional voting with simple majority "Union" or "Nullable" or 
"Union+Nullable".

Thanks. Dmitry.


From: Levi Morrison <morrison.l...@gmail.com>
Sent: Tuesday, April 26, 2016 17:47
To: Dmitry Stogov
Cc: Bob Weinand; internals; Joe Watkins
Subject: Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On 04/26/2016 05:19 PM, Bob Weinand wrote:
>>>
>>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@zend.com>:
>>>
>>> hi Levi,
>>>
>>> It looks like your "work" on "Nullable Types" RFC was intended to win
>>> time for this patch and block "Nullable Types" again.
>>> Actually, you have been blocking it for more than a year :(
>>>
>>> I'm going to push my own RFC for voting together with "Union Types".
>>>
>>> https://wiki.php.net/rfc/nullable_return_types
>>>
>>> At least, it has up to date implementation.
>>>
>>> We discussed this internally 2-3 weeks ago, and my politeness (or/and
>>> stupidity) allowed you  to pass your version for common discussion.
>>> Now I can see your real reason :(
>>>
>>> Both "Union Types" and "Nullable Types" may make sense, and both should
>>> be voted at the same time.
>>> Tomorrow is time to start voting. Right?
>>>
>>> Thanks. Dmitry.
>>>
>>>
>>> 
>>> From: Levi Morrison <morrison.l...@gmail.com>
>>> Sent: Tuesday, April 26, 2016 02:37
>>> To: internals
>>> Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types
>>>
>>> Internals,
>>>
>>> Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch
>>> for union types][1]. Please go download it and experiment with it.
>>>
>>> A few things to note:
>>>
>>>   * This patch includes intersection types. However, a type expression
>>> must be either a union type or an intersection type; it doesn't
>>> support both such as `Array | (Countable & Traversable)`.
>>>   * This patch adds `null`, `true` and `false` for type declarations.
>>>   * This patch includes conversion rules for weak types.
>>>   * It does not have short-hand for unions with null (`?Foo` being `Foo |
>>> Null`)
>>>
>>> These features (or omitted ones) are not necessarily what will be
>>> voted on. Rather this patch allows us to experiment with these
>>> features in code. This experience should be helpful for us to solidify
>>> how we actually feel about these features.
>>>
>>> I especially would like people to try out the conversion rules for
>>> scalar types as it has been a point of discussion.
>>>
>>>   [1]: https://github.com/php/php-src/pull/1887
>>
>> Hey Dmitry,
>>
>> Please, do not accuse us of blocking the nullables. This wasn't
>> intentional and rather a coincidence that we provided a patch right now.
>> First we wanted to concentrate our forces on getting a great 7.0 out
>> before starting this RFC (as it didn't make it in time for going into 7.0
>> too as we waited for result on scalar types in general first).
>> Then, as you're aware Levi had absolutely no time for a few months… Now,
>> he has time to manage things and we could move ahead quickly and write the
>> patch up.
>
> I know, we all like to make our best for PHP.
> Sorry, if I was too emotional.
>>
>> I'd like to hold first a formal (and binding) vote on whether "null |" or
>> "?" should be used (in case both RFCs pass). Rushing things through right
>> now might just us ending up with semantics the vast majority dislikes.
>
> I didn't exactly get, what do you propose. One RFC with voting for
> "Nullable" or "Union"?
>
> Thanks. Dmitry.
>
>>
>> Thanks,
>> Bob
>
>
>
>
>
>

I believe the intention here is to decide whether we do the short-hand
syntax for nullable types or only the long-form. I can understand the
rationale of not having both or at least dis-allowing the syntax to
mix them. For example, I don't think anyone really likes allowing
this: `?Array | Travsersable` as .

However, if the union types RFC does not pass then it seems odd (to me
at least) to use the expression `Foo | Null` instead of `?Foo`, but I
know Bob would like the long-form in all cases, hence why he would
like a vote. Joe seems to just want nullables to have an outcome so it
is no longer blocking typed properties.

Is that a correct summary, Bob and Joe?

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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

On 04/26/2016 05:19 PM, Bob Weinand wrote:

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@zend.com>:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch 
and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and 
stupidity) allowed you  to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be 
voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.



From: Levi Morrison <morrison.l...@gmail.com>
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch
for union types][1]. Please go download it and experiment with it.

A few things to note:

  * This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as `Array | (Countable & Traversable)`.
  * This patch adds `null`, `true` and `false` for type declarations.
  * This patch includes conversion rules for weak types.
  * It does not have short-hand for unions with null (`?Foo` being `Foo | Null`)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

  [1]: https://github.com/php/php-src/pull/1887

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't intentional and 
rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out before 
starting this RFC (as it didn't make it in time for going into 7.0 too as we 
waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now, he has 
time to manage things and we could move ahead quickly and write the patch up.

I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

I'd like to hold first a formal (and binding) vote on whether "null |" or "?" 
should be used (in case both RFCs pass). Rushing things through right now might just us ending up 
with semantics the vast majority dislikes.
I didn't exactly get, what do you propose. One RFC with voting for 
"Nullable" or "Union"?


Thanks. Dmitry.



Thanks,
Bob







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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

Hi Joe,

At first, I'm glad this implementation is ready.
At least it's possible to analyze its profs and cons.
I'm also sure that both RFCs have their opponents and advocates.

Now, I just like to make the final voting fair.

Thanks. Dmitry.

On 04/26/2016 05:13 PM, Joe Watkins wrote:

Afternoon Dmitry,

I started the implementation of this because unions and nullables 
appears to be in my way (typed properties).


At no point did Levi request an implementation. I decided, 
selfishly, to provide one because it's in my way, and we've been 
waiting so long already.


There is no conspiracy.

I would actually like it if nullable types came first, I would 
have preferred not to have my work on typed properties stopped also.


We don't always get what we want :)

Cheers
Joe

On Tue, Apr 26, 2016 at 2:33 PM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:


hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to
win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness
(or/and stupidity) allowed you  to pass your version for common
discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both
should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.



From: Levi Morrison <morrison.l...@gmail.com
<mailto:morrison.l...@gmail.com>>
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch
for union types][1]. Please go download it and experiment with it.

A few things to note:

  * This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as `Array | (Countable & Traversable)`.
  * This patch adds `null`, `true` and `false` for type declarations.
  * This patch includes conversion rules for weak types.
  * It does not have short-hand for unions with null (`?Foo` being
`Foo | Null`)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

  [1]: https://github.com/php/php-src/pull/1887

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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

On 04/26/2016 04:57 PM, Levi Morrison wrote:

On Tue, Apr 26, 2016 at 7:33 AM, Dmitry Stogov <dmi...@zend.com> wrote:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch 
and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and 
stupidity) allowed you  to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be 
voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

Dmitry,

I agree that union types and nullable types should be voted at the
same time. Union types is a large RFC and didn't have an
implementation until now. I think it is important that we have an
implementation to experiment wotj. I hope you can see how having an
implementation to experiment with is essential for both RFCs.

Please do not move any type related RFCs to voting; I am not
attempting to sabatoge nullable types. Please do not make such
accusations.

Levi Morrisont
Your "Nullable Types" RFC don't have up to date implementation. You took 
ownership on two competing RFCs, but make preference to one.
In our conversation, I took your point 3 times (delaying Nullable in 
2015, delaying my RFC for a week (while you have time), sending your RFC 
instead of mine, because they proposed almost the same).


I think, it's going to be fair, if now you take my point.

I don't like to argue. You got what you liked.
Now "Union Types" and "Nullable Types" should compete in fair way.

Thanks. Dmitry.



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

[PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for 
this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and 
stupidity) allowed you  to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be 
voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.



From: Levi Morrison 
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch
for union types][1]. Please go download it and experiment with it.

A few things to note:

  * This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as `Array | (Countable & Traversable)`.
  * This patch adds `null`, `true` and `false` for type declarations.
  * This patch includes conversion rules for weak types.
  * It does not have short-hand for unions with null (`?Foo` being `Foo | Null`)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

  [1]: https://github.com/php/php-src/pull/1887

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


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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 11:20 PM, Stanislav Malyshev wrote:

Hi!


No, but this is valid:

@atrr(); function foo() { ... }

That's perhaps a little too close for comfort...?

That's different syntax. If you put ; in the middle of statement, it can
change - "$c = $a + $b;" is not the same as "$c = $a; + $b;" - but
nobody thinks + can not be used because of that. As I said, << and >>
are existing operators too, so if you are creative enough, I'm sure you
can find cases like that too.


Hi Stas,

You may try to replace attribute syntax with @attr(...) (without 
semicolon) into our PHP parser.

Note that we have LALR grammar + restrictions caused by semantic actions.
If you are able to do this, I'll add it into the RFC as an option.

Thanks. Dmitry.

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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

This is another reason to use PHP layer on top on base attribute functionality.

Implementing caching would take just 3 additional lines of PHP code.


From: guilhermebla...@gmail.com <guilhermebla...@gmail.com>
Sent: Monday, April 25, 2016 17:22
To: Dmitry Stogov
Cc: Dominic Grostate; PHP internals
Subject: Re: [PHP-DEV] [RFC] PHP Attributes

Another thing that looks odd to me i that every time you call new 
ReflectionClass, a new reflection_object gets created.
Isn't there a way to get this "cached" somehow in zend_class_entry?

On Mon, Apr 25, 2016 at 10:11 AM, 
guilhermebla...@gmail.com<mailto:guilhermebla...@gmail.com> 
<guilhermebla...@gmail.com<mailto:guilhermebla...@gmail.com>> wrote:


On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:


On 04/22/2016 06:39 PM, 
guilhermebla...@gmail.com<mailto:guilhermebla...@gmail.com> wrote:

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:


On 04/22/2016 04:05 AM, <mailto:guilhermebla...@gmail.com> 
guilhermebla...@gmail.com<mailto:guilhermebla...@gmail.com> wrote:
Hi Dmitry,

As a previous suggester of metadata information built-in into PHP, and also one 
of developers of the most used metadata library written in PHP, I understand 
this feature implementation requires several design decisions and also a good 
understanding of specific situations users may require.

While I am a strong supporter of a more robust solution, this is already a good 
start.
A few things I'd like to ask for my own understanding and also suggestions too:

1- I understand you took a minimalistic approach towards a "dumb" 
implementation for attributes (when I mean "dumb", the idea here is towards a 
non-OO approach). Can you explain your motivations towards this approach?

I see two distinct approaches of implementation for this feature. Both of them 
have some common demands, like lazy initialization of metadata. Here they are:

- Simplistic approach, which lets consumers of the feature do all the work 
related to validation, assertion of valid keys, values, etc
This does not invalidate the ability to leverage of some features that a more 
robust implementation demands.

- Robust approach: language takes the burden of instantiating complex 
structures, validating, assertion of valid keys, values, if this complex 
structure is allowed to be instantiated in that given class, method, etc.

I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization during compilation - 
this is just not possible from implementation point of view.
Now attributes may be stored in opcache SHM and relive request boundary.
Objects can't relive requests.


I know that object instances are not cross-requests. Explicitly, I mentioned 
that both approaches require lazy-initialization (which means, whenever you 
call getAttributes() or getAttribute()).

What I mentioning is that your approach is basically a new key/value syntax 
that are used specifically for Attributes. We could easily turn this into a 
more robust approach if instead of defining key/value pairs, we instantiate 
objects or call functions. You already demonstrated interest to support 
<<ORM\Entity>> reusing the imports (which is our biggest headache in Doctrine 
Annotations), so why not issue constructor or function calls there? That would 
simplify the work needed for consumers and also add room for later improvements.

So basically in this example:

use Doctrine\ORM;

<<ORM\Entity("user")>>
class User {}

$reflClass = new \ReflectionClass("User");
var_dump($reflClass->getAttributes());

We'd be changing from this:

array(1) {
  ["Doctrine\ORM\Entity"]=>
  array(1) {
[0]=>
string(4) "user"
  }
}

Into this:

array(1) {
  ["Doctrine\ORM\Entity"]=>
  object(Doctrine\ORM\Entity)#1 (1) {
["tableName"]=>
string(4) "user"
  }
}

As I showed already, it's very easy to do this transformation at higher layer.

$reflClass = new \ReflectionClass("User");
$attributes = $reflClass->getAttributes()
foreach ($attributes as $key => &$val) {
$val = new $key(...$val);
}
var_dump($attributes);

Construction objects directly in Reflection*::getAttributes() method, doesn't 
make significant benefits and even makes limitation.

Sorry, but I don't see how limitations are added. If you call a function, 
static method or constructor, you actually add whole new level of 
possibilities, and I fail to see which limitations are added. Could you provide 
me one?

Calling the function/constructor/static method, not only helps to better 
segregate userland code, but it also adds subsequents extensibility. I can 
highlight examples:

- Support for Inheritance

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 05:11 PM, guilhermebla...@gmail.com wrote:



On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 04/22/2016 06:39 PM, guilhermebla...@gmail.com
<mailto:guilhermebla...@gmail.com> wrote:


On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:



On 04/22/2016 04:05 AM, guilhermebla...@gmail.com
<mailto:guilhermebla...@gmail.com> wrote:

Hi Dmitry,

As a previous suggester of metadata information built-in
into PHP, and also one of developers of the most used
metadata library written in PHP, I understand this feature
implementation requires several design decisions and also a
good understanding of specific situations users may require.

While I am a strong supporter of a more robust solution,
this is already a good start.
A few things I'd like to ask for my own understanding and
also suggestions too:

1- I understand you took a minimalistic approach towards a
"dumb" implementation for attributes (when I mean "dumb",
the idea here is towards a non-OO approach). Can you explain
your motivations towards this approach?

I see two distinct approaches of implementation for this
feature. Both of them have some common demands, like lazy
initialization of metadata. Here they are:

- Simplistic approach, which lets consumers of the feature
do all the work related to validation, assertion of valid
keys, values, etc
This does not invalidate the ability to leverage of some
features that a more robust implementation demands.

- Robust approach: language takes the burden of
instantiating complex structures, validating, assertion of
valid keys, values, if this complex structure is allowed to
be instantiated in that given class, method, etc.


I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization
during compilation - this is just not possible from
implementation point of view.
Now attributes may be stored in opcache SHM and relive
request boundary.
Objects can't relive requests.



I know that object instances are not cross-requests. Explicitly,
I mentioned that both approaches require lazy-initialization
(which means, whenever you call getAttributes() or getAttribute()).

What I mentioning is that your approach is basically a new
key/value syntax that are used specifically for Attributes. We
could easily turn this into a more robust approach if instead of
defining key/value pairs, we instantiate objects or call
functions. You already demonstrated interest to support
<<ORM\Entity>> reusing the imports (which is our biggest headache
in Doctrine Annotations), so why not issue constructor or
function calls there? That would simplify the work needed for
consumers and also add room for later improvements.
So basically in this example:

use Doctrine\ORM;

<<ORM\Entity("user")>>
class User {}

$reflClass = new \ReflectionClass("User");
var_dump($reflClass->getAttributes());

We'd be changing from this:

array(1) {
["Doctrine\ORM\Entity"]=>
array(1) {
[0]=>
string(4) "user"
  }
}

Into this:

array(1) {
["Doctrine\ORM\Entity"]=>
object(Doctrine\ORM\Entity)#1 (1) {
["tableName"]=>
string(4) "user"
  }
}


As I showed already, it's very easy to do this transformation at
higher layer.

$reflClass = new \ReflectionClass("User");
$attributes = $reflClass->getAttributes()
foreach ($attributes as $key => &$val) {
$val = new $key(...$val);
}
var_dump($attributes);

Construction objects directly in Reflection*::getAttributes()
method, doesn't make significant benefits and even makes limitation.


Sorry, but I don't see how limitations are added. If you call a 
function, static method or constructor, you actually add whole new 
level of possibilities, and I fail to see which limitations are added. 
Could you provide me one?


For example, I like to check an attribute existence, and I don't need to 
construct any objects.


Calling the function/constructor/static method, not only helps to 
better segregate userland code, but it also adds subsequents 
extensibility. I can highlight examples:


- Support for Inheritance and overrides, through @Inherit, @Override, 
etc. While you might not see how it could be used now, other 
developers might be weirdly creative.
- Targeting of annotations, such as limiting its scope to be only 
cl

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 02:28 PM, Joe Watkins wrote:

Morning internals,

This morning I attempted to prototype a dbc extension.

In my opinion, the patch, or internals, are not fit for the 
intended purpose.


At the moment, the *only* way to perform meta programming is going 
to be in userland. This is going to make it prohibitively slow, and 
rather pointless.


why? It's quite easy to use attributes in C extension.

if (op_array->attributes) {
zval *val = zend_hash_find_str(op_array->attributes, "requires", 
sizeof("requires")-1_;

if (val && Z_TYPE_P(val) == IS_ARRAY) {
  HashTable *ht = Z_ARRVAL_P(val);
  ZEND_HASH_FORECH_VAL(ht, val) {
...
  ZEND_HASH_FOREACH_END();
   }
}




None of the compiler API is exported: This means that AST is 
almost useless to internals unless it's a constant expression.

Do you mean C or PHP API?
What exactly do you like to be exported? zend_compile_expr()? It's not a 
problem to export it in 7.1.




There is a problem with zend extensions and fcall handlers, which 
we are not sure how to fix.


This is completely unrelated historical problem  :)


Working with AST is easy, working with opcodes directly is not.

Before we can have this, we must work on the AST API and allow 
extensions to transform AST with much better hooks than we have at the 
moment.
This is related to user extendable parser, that is definitely not a 
subject of this RFC.




I was excited to start working with this .. at the moment, I'm -1.


I got you.
Attributes are not especially for DbC and user extendable parser, and 
they are not a magic wand.

They may be an underlying layer for many things (including DbC).
But to reach what you want, you'll have to start from something anyway.

Thanks. Dmitry.


Cheers
Joe

PS. If anyone is interested http://github.com/krakjoe/dbc was my first 
attempt at interacting with the patch.





On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 04/25/2016 12:44 PM, Pierre Joye wrote:

hi Dmitry,

Awesome work! Thanks.

I do like you keep what was discussed last time. Make the basics
available and leave the rest to the applications (doctrine or
other).

I feel too that how the apps will interact with may need some more
discussions but other commented on it so I won't interfer here :).

I've collected the most interesting feedback at
https://wiki.php.net/rfc/attributes#open_issues
And I'm going to correct RFC and implementation rethinking these
questions.

Thanks. Dmitry.



    On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov
<dmi...@zend.com <mailto:dmi...@zend.com>> wrote:

The proposed by you "@..." syntax just won't fit into PHP
grammar, because @
used as silence operator.

Attribute, syntax is taken from HHVM. I don't see a big
reason to introduce
more fragmentation into PHP world.

Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
agree with Dmitry here. It makes no sense now to go with our own
syntax.

If any of the hhvm developers are around, we may get some
feedbacks
about their current APIs (using getAttributes) and if they
would like
to change one thing or another. That could (or must) part of
the PHP
specifications.

Cheers,



-- 
PHP Internals - PHP Runtime Development Mailing List

To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 12:44 PM, Pierre Joye wrote:

hi Dmitry,

Awesome work! Thanks.

I do like you keep what was discussed last time. Make the basics
available and leave the rest to the applications (doctrine or other).

I feel too that how the apps will interact with may need some more
discussions but other commented on it so I won't interfer here :).
I've collected the most interesting feedback at 
https://wiki.php.net/rfc/attributes#open_issues

And I'm going to correct RFC and implementation rethinking these questions.

Thanks. Dmitry.




On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov <dmi...@zend.com> wrote:

The proposed by you "@..." syntax just won't fit into PHP grammar, because @
used as silence operator.

Attribute, syntax is taken from HHVM. I don't see a big reason to introduce
more fragmentation into PHP world.

Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
agree with Dmitry here. It makes no sense now to go with our own
syntax.

If any of the hhvm developers are around, we may get some feedbacks
about their current APIs (using getAttributes) and if they would like
to change one thing or another. That could (or must) part of the PHP
specifications.

Cheers,



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 02:09 AM, Thomas Bley wrote:

The <<>> syntax comes with the problem that previous versions cannot ignore it 
on parsing.
So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then they 
write new frameworks for 7.1 which cannot be parsed with 7.0 and 5.x and so on.
For companies staying on Linux distributions with long term support on 7.0, 
this is rather a nightmare for both users and framework maintainers.
When choosing <<>> or any other non-backward compatible syntax for 7.1, there 
should be a patch for 7.0 to ignore the new syntax without parse errors.
Good point, but any syntax proposed for native attributes would break 
forward-compatibility as well.

The only choice to stay with doc-comments and do all the work at user level.

Thanks. Dmitry.



Regards
Thomas

Fleshgrinder wrote on 23.04.2016 17:29:


+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.

I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP code:

EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

  private const int MIN_BALANCE = 0;

  private int $balance;

  private Person $owner;

  @require $sum >= 0;
  @ensure $this->balance === (old::$balance + $sum);
  public function deposit(int $sum): void {
$this->balance += $sum;
  }

  @require $sum >= 0;
  @require $sum <= $this->balance - self::MIN_BALANCE;
  @ensure $this->balance === (old::$balance - $sum);
  public function withdraw(int $sum): void {
$this->balance -= $sum;
  }

  @deprecated 'for various reasons'
  public function setOwner(Person $wner): void {
$this->owner = $owner;
  }

}

@inheritDoc
class OverdraftAccount extends Account {

  private const int MIN_BALANCE = -1000;

}

?>

We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.

We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
  'unique_constraints' => [
'name' => 'user_unique',
'columns' => [ 'username' ],
  ],
  'indexes' => [
'name' => 'user_idx',
'clumns' => [ 'email' ],
  ],
  'schema' => 'schema_name',
];
class User {}

?>

--
Richard "Fleshgrinder" Fussenegger





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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/25/2016 06:23 AM, Stanislav Malyshev wrote:

Hi!


https://wiki.php.net/rfc/attributes

I've read the proposal and I like the idea of reviving the attributes
idea and the simplicity of the approach.

I have the following questions for it:

- Namespacing. Since the attribute names are not processed in any way
according to spec, it may be rather hard to ensure attribute
requirements from different domains do not conflict, and we do not get
into the same problem we've got into with class names before we
implemented namespaces. How it is planned to address the issue?


I'm going to extend RFC with namespace support.
Attribute name is going to be qualified string.


- The expressions support is nice, however I'm not sure I understand
what PHP application is supposed to do with syntax trees? I.e. taking
the example in the RFC, if I got AST\Node representing <
0)>>, how do I use it? Would I implement mini-PHP-engine in PHP to
evaluate such an expression? Am I supposed to use some other
functionality to do it? It is unclear.
I don't think promoting reimplementing PHP expressions in a myriad of
different ways (which all would be subtly different and distinct from
how PHP understands such expressions) is not good, and if we expose
those trees we should also provide means to work with them. Otherwise
any advanced usage of the feature would mean basically reimplementing
PHP engine in PHP.

AST is going to be processed and evaluated using php-ast extension.
Nikita was going to propose including it into core distribution.

As a side note, my personal opinion is that for about 90% of use cases
expressions are not needed. For 90% of those which are needed, string +
some form of eval would cover it's use case since all the'd be doing is
evaluating the expression and checking the resulting value.


This is a question. We may use AST expression or just strings.
In second case we miss syntax verification at compile time.
I'm going to describe the problem in RFC and set an additional voting 
question.


- As far as I can see, AST extension has no documentation except for
initial README. If it is going to end up in core, this needs to be
fixed. Preferably before it is merged into core.

- I would also consider moving AST namespace under \PHP since we have
this one reserved (unlike \AST which we did not reserve).

For me AST is the best choice here.



- Are attributes also allowed to apply to anonymous classes/functions?
Would the syntax still work in that case?


No. At least now.


_ I also think <<...>> syntax is ugly and @attribute syntax would be
much better (and also is used in Java attributes and Python decorators).
That's my personal opinion though.


@ is reserved for silence operator.

Thanks. Dmitry.


Thanks,



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 07:57 PM, Levi Morrison wrote:

On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd <dan...@basereality.com> wrote:

On 21 April 2016 at 22:13, Dmitry Stogov <dmi...@zend.com> wrote:

Hi,


I would like to present an RFC proposing support for native annotation.


Hi Dmitry,

Although everyone will have an opinion about the syntax, I think there
is one criticism that should be thought about; the chosen syntax isn't
future expandable to other concerns.

People have talked about "design by contract" RFCs where annotation
like data is readable by the engine. The current proposed syntax
_could_ be used to store DBC data, but it would not be clear what
would be annotation data to read by the application, and what was DBC
data to be read by the engine.

Changing the proposed syntax to be something like @attr(...) would
allow it to be expanded in the future by adding a @contract(...)
construct:

@attr(test($a + $b > 0))   // This is attribute data read by userland code
@contract(require($a + $b > 0, 'InvalidFooArgsException'))  // This is
DBC data read by the engine.
function foo($a, $b) {
 ...
}

Making features be compatible with future features would avoid a lot
of potential pain down the road.

Genuine question[1]: how is @attr() different than `<<attr()>>`? Also,
isn't `@attr()` 100% valid user-land code today that can precede
function or constant declarations?

@attr() - is a valid "silenced" call to function named "attr".
This syntax can't be reused.

Thanks. Dmitry.




   [1] I don't like that I have to make that explicit but it is what it is.



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 07:03 PM, Dan Ackroyd wrote:

On 21 April 2016 at 22:13, Dmitry Stogov <dmi...@zend.com> wrote:

Hi,


I would like to present an RFC proposing support for native annotation.


Hi Dmitry,

Although everyone will have an opinion about the syntax, I think there
is one criticism that should be thought about; the chosen syntax isn't
future expandable to other concerns.

People have talked about "design by contract" RFCs where annotation
like data is readable by the engine. The current proposed syntax
_could_ be used to store DBC data, but it would not be clear what
would be annotation data to read by the application, and what was DBC
data to be read by the engine.

Changing the proposed syntax to be something like @attr(...) would
allow it to be expanded in the future by adding a @contract(...)
construct:

@attr(test($a + $b > 0))   // This is attribute data read by userland code
@contract(require($a + $b > 0, 'InvalidFooArgsException'))  // This is
DBC data read by the engine.
function foo($a, $b) {
 ...
}

Making features be compatible with future features would avoid a lot
of potential pain down the road.

cheers
Dan

"@..." syntax can't work. @ - is a silence operator.

<<Contract\require($a + $b > 0, 'InvalidFooArgsException')>> - this is 
not really worse than your example.


I know, any syntax is going to be loved by ones and hated by others...
It's not possible to satisfy everyone.

Thanks. Dmitry.



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 12:34 AM, Yasuo Ohgaki wrote:

Hi Dimitry,

On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov <dmi...@zend.com> wrote:

I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and later may 
be accessed (node by node) in PHP extensions, preprocessors and PHP scripts their selves. 
I think this ability may be useful for "Design By Contract", other formal 
verification systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.

Nice RFC!
Attributes are always evaluated, right? i.e. No INI switch nor declare
to control behavior.
Just making sure.

Attributes are always parsed together with PHP script and stored internally.
Then you may access them through Reflection*::getAttributes() or in C 
extensions through native API.


AST in attribute values is not evaluated.

Thanks. Dmitry.



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] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/23/2016 06:29 PM, Fleshgrinder wrote:

+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I would need a co-author :)



I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.


Different languages names this differently.
I may add an additional voting question - "annotation vs attributes?".



I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

completely disagree.
Each value in multi-value attribute may have its own meaning. e.g. 
<>




I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP code:

EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

   private const int MIN_BALANCE = 0;

   private int $balance;

   private Person $owner;

   @require $sum >= 0;
   @ensure $this->balance === (old::$balance + $sum);
   public function deposit(int $sum): void {
 $this->balance += $sum;
   }

   @require $sum >= 0;
   @require $sum <= $this->balance - self::MIN_BALANCE;
   @ensure $this->balance === (old::$balance - $sum);
   public function withdraw(int $sum): void {
 $this->balance -= $sum;
   }

   @deprecated 'for various reasons'
   public function setOwner(Person $wner): void {
 $this->owner = $owner;
   }

}

@inheritDoc
class OverdraftAccount extends Account {

   private const int MIN_BALANCE = -1000;

}

?>

You should try to implement this syntax to understand the problem.
It leads to parse conflicts.


We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.


This RFC is not going to propose coding standards.


We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
   'unique_constraints' => [
 'name' => 'user_unique',
 'columns' => [ 'username' ],
   ],
   'indexes' => [
 'name' => 'user_idx',
 'clumns' => [ 'email' ],
   ],
   'schema' => 'schema_name',
];
class User {}

?>


Agree. Namespaces looks better than "__" prefixes.

Thanks. Dmitry.

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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 05:02 PM, Thomas Punt wrote:

Hi!


From: dmi...@zend.com

On 04/22/2016 02:46 PM, Thomas Punt wrote:
Hi Dmitry!

Just a couple of comments on this:

1. I'd definitely reuse the php-ast extension for parsing the code into an
AST. It performs a number of transformations on PHP's underlying AST
that make it much nicer to use (namely better consistency). It is also
less fragile by having the abstraction between PHP's internal AST and
the AST that is exposed to userland (enabling for internal AST changes
without impacting the AST exposed to userland).

I'm not sure. Both approaches make sense.

Whilst fragility is a concern, a bigger problem with not reusing
ast\parse_code() is that the AST produced will be different in even the
simplest of cases. For example, take the following simple expression:

$a> 2

With your attributes branch, this will produce an AST of:

object(ast\Node)#2 (4) {
 ["kind"]=> int(521) // ZEND_AST_GREATER
 ["flags"]=> int(0)
 ["lineno"]=> int(1)
 ["children"]=> [...]
}

Whereas with ast\parse_code(), the following AST will be produced:

object(ast\Node)#2 (4) {
 ["kind"]=> int(520) // AST_BINARY_OP
 ["flags"]=> int(256) // BINARY_IS_GREATER
 ["lineno"]=> int(1)
 ["children"]=> [...]
}

The php-ast extension transforms the special node types for>,>=, <, <=
into AST_BINARY_OP nodes with different flags set. This is just one
difference of many between the internal AST and the AST produced by
the php-ast extension.


This is initial implementation details, and they are going to be fixed.
If we decide to use AST in attributes, getAttributes() outout are going 
to be 100% compatible with php-ast.





2. You mentioned about moving some of the php-ast extension into core.
I wonder if it would be better to just move the whole extension into the
core first, and then enable this functionality if the php-ast extension is
enabled.

Even if we move php-ast into core (I think we will do it), it's going to
be optional.
However attributes should always work.

If we're going to reuse ast\parse_code(), then we will need the whole php-ast
extension in the core. It could therefore be made similar to the pcre, date,
Reflection, SPL, etc extensions, where it cannot be disabled.


Right,  but this is out of scope of this RFC.
Nikita was going to propose moving php-ast into core soon.

Thanks. Dmitry.




Also, slightly tangential, but the RFC says attributes are supported on
class constants, yet doc comments (IIRC) are not. I wonder if support
for doc comments should be added for class constants?

it is already implemented.

Oh right, my mistake. It does not seem to be exposed through php-ast or
reflection then.


Thanks. Dmitry.

Thanks,
Tom

-Tom



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 03:33 PM, Fleshgrinder wrote:

I am not arguing against the RFC nor the feature itself, on the
contrary, I like it. I just do not like certain aspects and design
decisions of it; that is all.

Configuration and AOP are the best usecases for annotations and those
should be stressed in the RFC. They are not mentioned at all!

Another usecase that I am missing completely is the usage of it for
documentation and static code analysis. I already mentioned the /throws/
annotation, this could help e.g. IDEs to warn you better about uncatched
exceptions form methods you call.

DbC is a possible usecase but better implemented at language level. The
RFC could mention the possibility of it. However, right now it is the
sole usecase beside the not very PHP applicable `<>` and
`<>` examples.

You see, this is more a problem of the RFC text and not of the feature. ;)

Another think I complained about is the proposed syntax because it makes
annotations look like function calls, which they simply are not and will
not be. The syntax is misleading and a possible built-in functionality
of reactive annotations (not saying we need them) at the language level
for userland is blocked. I know I just repeated myself.

The extension you mentioned works just fine without the brackets.

   @invariant CONDITION;
   class A {

 @ensure CONDITION;
 @require CONDITION;
 function f(){}

   }

The proposed by you "@..." syntax just won't fit into PHP grammar, 
because @ used as silence operator.


Attribute, syntax is taken from HHVM. I don't see a big reason to 
introduce more fragmentation into PHP world.


Personally I don't see "foo(a,b,c)" as a function, I see this as a 
predicate.


It's possible to extend RFC with additional use-cases, but the longer 
the RFC the less people read it.


Thanks. Dmitry.

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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/24/2016 11:24 AM, Fleshgrinder wrote:

The invariant could also be added as an additional branch to the class
instead of a method, since it would not work like a method.

   class A {} invariant {}

   function f() {} require {} ensure {}

This would also align nicely with closures and anonymous classes, which
is kind a problematic with annotations.

   $A = new class {} invariant {};

   $f = function () {} require {} ensure {};

The only thing that remains that might be of interest to both is
`@throws` but that was not discussed at all as of yet.

   use Ns\SomeException;

   @throws SomeException
   function f() {

   }

This is at least how one would expect it to work and it is something
that should be covered by annotations and not as part of the language.
The ABNF should account for that:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-REFERENCE / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

Where PHP references are any of the already possible ones:

   use F\Q\C\N;

   @annotation \F\Q\C\N
   @annotation N
   @annotation \F\Q\C\N::CONSTANT
   @annotation N::CONSTANT
   @annotation \F\Q\C\N::function()
   @annotation N::function()
   @annotation \F\Q\C\N::$variable
   @annotation N::$variable

I also though some more about function support for annotations and this
would actually be a nice thing for userland.

   annotation deprecated(Reflection $element, string $message = '') {
 @trigger_error($message, E_USER_DEPRECATED);
   }

   @deprecated('because')
   function x() {}

   @deprecated
   function y() {}

This would allow users to implement simple and easy reactive annotations
in userland. Even if this could or should be an extension of the feature
in the future, it should be thought about know. Simply because the
brackets make sense if such a feature is to be implemented. ;)

Looks interesting, but try to think where the "annotation deprecated" 
should be declared,to be visible in every compiled script, when the 
corresponding code should be called (in what context), what if we need 
to do something at compile-time? Single answers to these question are 
going to be great for "deprecated" use case, however they will limit 
usability for other cases.


Thanks. Dmitry.

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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 06:56 PM, Larry Garfield wrote:

On 4/22/16 10:39 AM, guilhermebla...@gmail.com wrote:

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmi...@zend.com> wrote:




3- Did you put any thought on inheritance? What I mentioned in 
comment #1

is even smaller than what you implemented in RFC.
Assuming you keep the RFC approach, did you consider support overrides,
inherit, etc?


In my opinion, attributes don't have to be inherited.
If you think differently - please explain your point.


Of source I can.
A simple case would be to increate visibility of the inherited 
property. It
was declared in a parent class as protected, but now you want public, 
and

you still want to keep all parent defined Attributes.
Another example is like we do in Doctrine. We support a callback system
which we named as lifetime callbacks. Pre-persist is one of them, 
which is

called every time a given Entity is about to be persisted into DB. When
you're dealing with inheritance, you can potentially override the method
content and you still want to trigger the same operation as if it was
untouched. Example:

use Doctrine\ORM;

trait Timestampable {
 protected $created;
 protected $updated;

 <<ORM\PrePersist>>
 public function prePersist() {
 $this->created = $this->updated = new \DateTime("now");
 }

 <<ORM\PreUpdate>>
 public function preUpdate() {
 $this->updated = new \DateTime("now");
 }
}

<<ORM\Entity>>
class User {
 use Timestampable;

 public function prePersist() {
 // Add my custom logic
 }
}

The implication is that through a simplistic approach, inheriting (or
overriding) is not clear and I can't figure it out an easy way to 
achieve

that.
Now if we go towards calling a function or class constructor like I
mentioned before, then we could easily build structures like __Inherit,
__Override, etc.



Here's another example from a Doctrine-using project I built a while 
back.  (Not the exact code, but the same concept; I've adapted it to 
PHP 7 types as well):


interface Ownable {
  public function getOwner() : string;
  public function setOwner(string $u);
  public function isUnowned() : bool;
}

trait OwnableTrait {

  /** @ORM\String **/
  private $owner = '';

  public getOwner() : string {
return $this->owner;
  }

  public setOwner(string $u) {
$this->owner = $owner;
  }

  public function isUnowned() : bool {
return $this->owner == '';
  }
}

/** @ORM\Entity */
class Product implements Ownable {
  use OwnableTrait;

  // ...
}

class Widget extends Product {
// ...
}

For annotations to work for this use case, reflecting on the 
properties of Widget would need to include $owner, and it would need 
to include the ORM\String annotation.  (True regardless of whether 
annotations are array or object based.)


In your example you don't override the property, so you'll able to see 
attributes of your property.


>
protected $x;
}
class Foo {
use T;
}
$r = new ReflectionClass("Foo");
$prop = $r->getProperty("x");
var_dump($prop->getAttributes());
?>

$ sapi/cli/php attr7.php
array(1) {
  ["test"]=>
  bool(true)
}

Works fine.

Thanks. Dmitry.

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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote:


On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 04/22/2016 04:05 AM, guilhermebla...@gmail.com
<mailto:guilhermebla...@gmail.com> wrote:

Hi Dmitry,

As a previous suggester of metadata information built-in into
PHP, and also one of developers of the most used metadata library
written in PHP, I understand this feature implementation requires
several design decisions and also a good understanding of
specific situations users may require.

While I am a strong supporter of a more robust solution, this is
already a good start.
A few things I'd like to ask for my own understanding and also
suggestions too:

1- I understand you took a minimalistic approach towards a "dumb"
implementation for attributes (when I mean "dumb", the idea here
is towards a non-OO approach). Can you explain your motivations
towards this approach?

I see two distinct approaches of implementation for this feature.
Both of them have some common demands, like lazy initialization
of metadata. Here they are:

- Simplistic approach, which lets consumers of the feature do all
the work related to validation, assertion of valid keys, values, etc
This does not invalidate the ability to leverage of some features
that a more robust implementation demands.

- Robust approach: language takes the burden of instantiating
complex structures, validating, assertion of valid keys, values,
if this complex structure is allowed to be instantiated in that
given class, method, etc.


I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization during
compilation - this is just not possible from implementation point
of view.
Now attributes may be stored in opcache SHM and relive request
boundary.
Objects can't relive requests.



I know that object instances are not cross-requests. Explicitly, I 
mentioned that both approaches require lazy-initialization (which 
means, whenever you call getAttributes() or getAttribute()).


What I mentioning is that your approach is basically a new key/value 
syntax that are used specifically for Attributes. We could easily turn 
this into a more robust approach if instead of defining key/value 
pairs, we instantiate objects or call functions. You already 
demonstrated interest to support <<ORM\Entity>> reusing the imports 
(which is our biggest headache in Doctrine Annotations), so why not 
issue constructor or function calls there? That would simplify the 
work needed for consumers and also add room for later improvements.

So basically in this example:

use Doctrine\ORM;

<<ORM\Entity("user")>>
class User {}

$reflClass = new \ReflectionClass("User");
var_dump($reflClass->getAttributes());

We'd be changing from this:

array(1) {
["Doctrine\ORM\Entity"]=>
  array(1) {
[0]=>
string(4) "user"
  }
}

Into this:

array(1) {
["Doctrine\ORM\Entity"]=>
object(Doctrine\ORM\Entity)#1 (1) {
["tableName"]=>
string(4) "user"
  }
}


As I showed already, it's very easy to do this transformation at higher 
layer.


$reflClass = new \ReflectionClass("User");
$attributes = $reflClass->getAttributes()
foreach ($attributes as $key => &$val) {
$val = new $key(...$val);
}
var_dump($attributes);

Construction objects directly in Reflection*::getAttributes() method, 
doesn't make significant benefits and even makes limitation.







1- Your approach is basically defining an array. Could you
explain your line of thinking on why you didn't consider a syntax
like the one below?

<["key" => "value"]>
class Foo {}

I didn't try to invite new syntax. Just completely took it from HHVM.


My idea was based on your current proposal, which is basically a way 
to define key/value pairs.
If you decide to go minimalistic, that is probably my best line of 
thinking.






2- I see that you added support over functions, classes,
constants and properties. According to the RFC, getAttributes()
was added over ReflectionFunction. Is there a reason why support
was not added to methods (ReflectionMethod extends
ReflectionFunctionAbstract, which was not mentioned on RFC)? Any
reason to not support it in function/method parameters?

ReflectionMethod is a child of ReflectinFunction, so it's supported.

Attributes are allowed for the same entities as doc-comments (they
are not allowed for parameters)


I was asking if there was a purpose to not support Attributes over 
ReflectionParameter. Example:


class Foo {
public function bar(<> Bar $bar) : bool {
// ...
}
}

$reflClass = new \Refl

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:46 PM, Thomas Punt wrote:

Hi Dmitry!


Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and later may 
be accessed (node by node) in PHP extensions, preprocessors and PHP scripts their selves. 
I think this ability may be useful for "Design By Contract", other formal 
verification systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.

Just a couple of comments on this:

1. I'd definitely reuse the php-ast extension for parsing the code into an
AST. It performs a number of transformations on PHP's underlying AST
that make it much nicer to use (namely better consistency). It is also
less fragile by having the abstraction between PHP's internal AST and
the AST that is exposed to userland (enabling for internal AST changes
without impacting the AST exposed to userland).

I'm not sure. Both approaches make sense.



2. You mentioned about moving some of the php-ast extension into core.
I wonder if it would be better to just move the whole extension into the
core first, and then enable this functionality if the php-ast extension is
enabled.
Even if we move php-ast into core (I think we will do it), it's going to 
be optional.

However attributes should always work.



Also, slightly tangential, but the RFC says attributes are supported on
class constants, yet doc comments (IIRC) are not. I wonder if support
for doc comments should be added for class constants?


it is already implemented.

Thanks. Dmitry.


Thanks,
Tom 



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

<> works fine


sapi/cli/php attr6.php
array(1) {
  ["Entity"]=>
  bool(true)
}


$ cat attr6.php
>
function foo() {}
$r = new ReflectionFunction("foo");
var_dump($r->getAttributes());
?>
[dmitry@tpl2 CGI-DEBUG]$ sapi/cli/php attr6.php
array(1) {
  ["Entity"]=>
  bool(true)
}


<<ORM\Entity>> - doesn't work now, but I'll implement this and extend RFC on 
next week.


Thanks. Dmitry.


From: Dominic Grostate <codekest...@googlemail.com>
Sent: Friday, April 22, 2016 11:31
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] PHP Attributes


I'm having a crack at it now.  Seeing if I can use it to plug a new Annotation 
driver for Doctrine.

Couple of things I've found so far are:

<> with empty args doesn't work.
<<ORM\Entity>> namespace doesn't work.

On the subject of using @, that could denote a class constructor, unless 
someone already mentioned that.

On 22 Apr 2016 12:44 a.m., "Dmitry Stogov" 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:


On 04/22/2016 02:16 AM, Dominic Grostate wrote:

This is amazing.  It would actually allow us to implement our automated 
assertions ourselves, as opposed to requiring it within the language.

this was the idea - to give a good tool instead of implementing every possible 
use-case in the language.



Could it also support references?

<<sanitize(&$a)>>
function foo($a) {

}

yes. "&$a" is a valid PHP expression.

If you plan to use this, I would appreciate, if you to build the patched PHP 
and try it.
The early we find problems the better feature we will get at the end.

Thanks. Dmitry.


On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:
Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and 
later may be accessed (node by node) in PHP extensions, preprocessors and PHP 
scripts their selves. I think this ability may be useful for "Design By 
Contract", other formal verification systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 05:15 AM, Sara Golemon wrote:

On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov <dmi...@zend.com> wrote:

I would like to present an RFC proposing support for native annotation.


I'm trying to imagine where the benefit of non-constant expressions comes in.

<<foo($a < 1)>>

Assuming we roll in php-ast at the same time (which is a big addition,
IMO, and deserves its own separate RFC), what are users meant to do
with this?  Even if there's a use-case here, one could accomplish the
same thing with:

<<foo('$a < 1')>>

And manually running that string into php-ast if that's what the caller wanted.


Good point. It's really not a big deal to run 
ast\parse_code($r->getAttributes()["foo"])

This would simplify the implementation a bit.


Also, maybe I missed it, but I didn't see an answer to the question of
ambiguity between parsing the above as a straight string, versus
parsing it as a ZEND_AST_ZVAL.  I'm sure the answer is "If the AST
tree is just a ZVAL, then it's provided as the compile-time
expression, but what about something else like this:

<<foo(1+1)>>

Logically, this is reducible to a single compile-time value, but it's
a complex expression, so would it be the value int(2)? Or
ZEND_AST_BINARY_OP(int(1), int(1))?

Currently this going to be an AST - ZEND_AST_BINARY_OP(int(1), int(1))


I just think that over-engineers what should be a simple annotation feature.


This makes sense. I think, I'll follow your suggestion.
The only missing ability is syntax check for  attribute values.



All that said, I love the proposal overall, and I can't wait to
propose builtin annotations like <<__Memoize>>, <<__Mock>>, and
similar.

I'm looking forward as well. :)

Thanks. Dmitry.



-Sara



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

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:

Hi Dmitry,

As a previous suggester of metadata information built-in into PHP, and 
also one of developers of the most used metadata library written in 
PHP, I understand this feature implementation requires several design 
decisions and also a good understanding of specific situations users 
may require.


While I am a strong supporter of a more robust solution, this is 
already a good start.
A few things I'd like to ask for my own understanding and also 
suggestions too:


1- I understand you took a minimalistic approach towards a "dumb" 
implementation for attributes (when I mean "dumb", the idea here is 
towards a non-OO approach). Can you explain your motivations towards 
this approach?


I see two distinct approaches of implementation for this feature. Both 
of them have some common demands, like lazy initialization of 
metadata. Here they are:


- Simplistic approach, which lets consumers of the feature do all the 
work related to validation, assertion of valid keys, values, etc
This does not invalidate the ability to leverage of some features that 
a more robust implementation demands.


- Robust approach: language takes the burden of instantiating complex 
structures, validating, assertion of valid keys, values, if this 
complex structure is allowed to be instantiated in that given class, 
method, etc.


I didn't exactly understand what do you suggest.
If you are talking about Attribute objects initialization during 
compilation - this is just not possible from implementation point of view.

Now attributes may be stored in opcache SHM and relive request boundary.
Objects can't relive requests.


1- Your approach is basically defining an array. Could you explain 
your line of thinking on why you didn't consider a syntax like the one 
below?


<["key" => "value"]>
class Foo {}

I didn't try to invite new syntax. Just completely took it from HHVM.



2- I see that you added support over functions, classes, constants and 
properties. According to the RFC, getAttributes() was added over 
ReflectionFunction. Is there a reason why support was not added to 
methods (ReflectionMethod extends ReflectionFunctionAbstract, which 
was not mentioned on RFC)? Any reason to not support it in 
function/method parameters?

ReflectionMethod is a child of ReflectinFunction, so it's supported.
Attributes are allowed for the same entities as doc-comments (they are 
not allowed for parameters)




3- Did you put any thought on inheritance? What I mentioned in comment 
#1 is even smaller than what you implemented in RFC.
Assuming you keep the RFC approach, did you consider support 
overrides, inherit, etc?


In my opinion, attributes don't have to be inherited.
If you think differently - please explain your point.


4- I understand that a more robust attribute solution would be 
required to achieve this, but one of the biggest advantages of AOP is 
the ability to perform custom logic before, after or around... 
However, I don't know if any kind of triggers came in your head or are 
planned as a future RFC.
Let me highlight one example: Every time a class, property or method 
is called that is annotated as <>, I would like to issue 
an E_USER_DEPRECATED warning. A trigger-like solution would be 
required. Did this concept came to your mind?

This is not a subject of this RFC.
Attributes provides a storage for metadata, but don't define how to use 
them.

Especially, for your use-case:
1) it's possible to create preprocessor that embeds corresponding 
trigger_error() call
2) it's possible to write a PHP extension that plugs-into compiler chain 
and checks <> attribute for each compiles function, then 
sets ZEND_ACC_DEPRECATED flag
3) It's also possible to override DO_FCALL opcodes and perform checks 
there (this is inefficient)


Thanks. Dmitry.





Regards,

On Thu, Apr 21, 2016 at 7:44 PM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 04/22/2016 02:16 AM, Dominic Grostate wrote:


This is amazing.  It would actually allow us to implement our
automated assertions ourselves, as opposed to requiring it
within the language.

this was the idea - to give a good tool instead of implementing
every possible use-case in the language.

Could it also support references?

<<sanitize(&$a)>>
function foo($a) {

}

yes. "&$a" is a valid PHP expression.

If you plan to use this, I would appreciate, if you to build the
patched PHP and try it.
The early we find problems the better feature we will get at the end.

Thanks. Dmitry.


On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" <dmi...@zend.com
<mailto:dmi...@zend.com> <mailto:dmi...@zend.com
<mailto:dmi...@zend.com>>> wrote:

Hi,


I 

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:16 AM, Dominic Grostate wrote:


This is amazing.  It would actually allow us to implement our 
automated assertions ourselves, as opposed to requiring it within the 
language.


this was the idea - to give a good tool instead of implementing every 
possible use-case in the language.



Could it also support references?

<<sanitize(&$a)>>
function foo($a) {

}


yes. "&$a" is a valid PHP expression.

If you plan to use this, I would appreciate, if you to build the patched 
PHP and try it.

The early we find problems the better feature we will get at the end.

Thanks. Dmitry.

On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:


Hi,


I would like to present an RFC proposing support for native
annotation.

The naming, syntax and behavior are mostly influenced by HHVM
Hack, but not exactly the same.

The most interesting difference is an ability to use arbitrary PHP
expressions as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax
Trees, and later may be accessed (node by node) in PHP extensions,
preprocessors and PHP scripts their selves. I think this ability
may be useful for "Design By Contract", other formal verification
systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to
doc-comment approach that uses not well defined syntax, and even
not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:09 AM, Colin O'Dell wrote:

> A more robust alternative would be something along the same lines that
> Doctrine uses: Make annotations actual classes.

Just spitballing here - what if both approaches were supported, but 
class-based annotations were prefixed with a special character 
(perhaps "@") to differentiate them?  For example:


<>
<<@ORM\Entity(table => "foo")>>
class Foo {
// ...
}

namespace ORM;
class Entity implements \Attribute {
// ...
}

$r = new ReflectionClass('ORM\Entity');
var_dump($r->getAttributes());

-

array(2) {
["ArbitraryAnnotation"]=>
string(11) "Hello world"
["ORM\Entity"] =>
object(ORM\Entity)#1 (0) { ... }
}

-

Again, I'm not necessarily advocating this - just throwing the idea 
out there for discussion.


Current proposal doen't support this, but this may be a good idea.
1) Attribute names might be not just strings, but also namespace qualified.
2) They may be optionally prefexed by some special character.

To create or not to create attribute objects is the question for next 
layer, but the base layer should provide necessary information.


Thanks. Dmitry.




Regards,

Colin

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:02 AM, Ryan Pallas wrote:



On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:



About expressions, isn't there an ambigoutiy? <<test(1)>> is a
"plain" name, value based attribute. But it could also be an
ast\node of a function call to "test(1)"

even in AST scalars are scalars.
so <<test(1+2)>> would return: ast\node "+" with two children
int(1) and int(2).

I am wondering if they shouldn't get their own start/end signs
to clear that up, <<<test(1)>> vs <<test(1)>>.


no need for extra complication.

Since the encapsulated meta-data is an AST, and as you say any valid 
php expression will be valid here, what about bit shifting?


<<Test(FOO >> BAR)>>
This works because attributes are implemented as native part of 
context-free PHP grammar.


Are there concerns about finding the T_SR token, which is also the end 
annotation symbol? I've not done any work in the parser, so excuse me 
if that is an insanely stupid question :)

Not a problem. Better to get false alarm then miss a real one :)


Otherwise, I think this RFC looks great, and appreciate your work on 
this :)



Thanks. Dmitry.


Ryan

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 01:03 AM, Benjamin Eberlei wrote:


On Thu, Apr 21, 2016 at 11:13 PM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:


Hi,


I would like to present an RFC proposing support for native
annotation.

The naming, syntax and behavior are mostly influenced by HHVM
Hack, but not exactly the same.

The most interesting difference is an ability to use arbitrary PHP
expressions as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax
Trees, and later may be accessed (node by node) in PHP extensions,
preprocessors and PHP scripts their selves. I think this ability
may be useful for "Design By Contract", other formal verification
systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to
doc-comment approach that uses not well defined syntax, and even
not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


I love it!

Syntax is good, and i like that it just returns plain arrays. 
Everything else (more formal) can be added on top by Doctrine 
Annotations for example.


thanks for support :)


About expressions, isn't there an ambigoutiy? <<test(1)>> is a "plain" 
name, value based attribute. But it could also be an ast\node of a 
function call to "test(1)"

even in AST scalars are scalars.
so <<test(1+2)>> would return: ast\node "+" with two children int(1) and 
int(2).


I am wondering if they shouldn't get their own start/end signs to 
clear that up, <<<test(1)>> vs <<test(1)>>.


no need for extra complication.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 12:52 AM, Larry Garfield wrote:

On 4/21/16 4:13 PM, Dmitry Stogov wrote:

Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, 
but not exactly the same.


The most interesting difference is an ability to use arbitrary PHP 
expressions as attribute values.


These expressions are not evaluated, but stored as Abstract Syntax 
Trees, and later may be accessed (node by node) in PHP extensions, 
preprocessors and PHP scripts their selves. I think this ability may 
be useful for "Design By Contract", other formal verification 
systems, Aspect Oriented Programming, etc



https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to 
doc-comment approach that uses not well defined syntax, and even not 
parsed by PHP itself.



Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.


Thanks, Dmitry!  In concept I am in favor of syntax-native 
annotations, although I have some concerns with the specifics of the 
proposal.  Thoughts in no particular order:


First, for the getAttributes() reflection method, please oh please 
don't return array-or-false.  That's horrible.  Just return an empty 
array if there aren't any, as that makes getAttributes() entirely type 
safe and saves all callers from a mandatory if-check.  (See 
http://www.garfieldtech.com/blog/empty-return-values for more 
information.)

Makes sense. I may change this.


The reflection section further indicates that the type of the result 
is variable, which means I cannot know in advance if I'm going to get 
back a scalar or an array.  If we go with this free-form approach, I'd 
honestly prefer to always get back an array, even for single value, so 
that I can always know the type I'm dealing with. (Since I cannot 
enforce a given attribute to be single-value.)


I'm not sure yet. both decisions may make sense. If I expect just a 
single value, I'll have to check the number of elements (or just ignore 
values above the first).


For the expression example:

<<test($a  +  $b   >  0)>>
function  foo($a,  $b)  {
}


It is not at all clear to me what scope the annotation's $a and $b 
exist in.  Are the they same $a and $b as in the function signature? 
If so, what happens if I reflect the function before ever calling it?
This is just an AST. It may contain any valid PHP expression syntax, but 
variable, functions and constants don't have to be valid.



How can I evaluate test?
I hope this functionality will be provided by php-ast extension. 
Currently, it is not a problem to reconstruct PHP source from AST and 
then use regular eval().

In general, we may find a more efficient way.

Or are they inherited from the global scope at the time of 
declaration?  (That scares me a great deal.)  I don't know what to 
make of that at all.
AST is going to be mainly used by extension and pre-processors (like AOT 
and DBC), but in general, they also may be used directly in scripts.


<<test($a  +  $b   >  0)>>
function  foo($a,  $b)  {
ast_eval(RefelectionFunction(__FUNCTION__)->getAttributes()["test"]);
}


DB
In the "Attribute syntax" section, the text says the tokens are the 
left and right double-angle character, as used for quotations in some 
European languages.  The rest of the text says it's two left/right 
carrot characters, as seen above the comma and period on US 
keyboards.  I'm assuming the former is just a typo/auto-correct bug.


yeah, computers think they are too smart :)


If I read correctly, the following two would be semantically identical:

<<One, Two>>
function foo() {}

<>
<>
function foo() {}


right


Is there a reason you chose the name "attribute" rather than 
"annotations", which seems at least in PHP to be the more common term 
for this type of declaration?


I took the name from HHVM. Personally, I don't care about naming at all.



It appears that the annotations themselves are entirely free-form.
no. they are parsed according to PHP expression syntax rules. syntax 
mistakes in attributes are going to be caught at compile time.


At the risk of expanding the typing debate, this concerns me as then 
all we're adding is a new way to parse undocumented, undefined 
anonymous structs.  How can I say what annotations mean what for my 
ORM, or routing system, or whatever?  We're back to, essentially, 
out-of-band documentation of big anonymous structs (aka associative 
arrays).


A more robust alternative would be something along the same lines that 
Doctrine uses: Make annotations actual classes.  To wit:



<>
<<AnotherThing('stuff')>>
<<MoreThing(1, 2, 3)>>
function foo($a, $b) { }

Where AThing, AnotherThing, and MoreThing are defined classes, and 
subject to namespaces and use statements.  Then what gets returned 
from getAttributes(

[PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and 
later may be accessed (node by node) in PHP extensions, preprocessors and PHP 
scripts their selves. I think this ability may be useful for "Design By 
Contract", other formal verification systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] Safe timeout handling

[Dmitry Stogov]

On 04/20/2016 08:40 PM, Bob Weinand wrote:


Am 20.04.2016 um 18:22 schrieb Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>>:




On 04/20/2016 06:24 PM, Matt Wilmas wrote:

Hi Dmitry,

- Original Message -
From: "Dmitry Stogov"
Sent: Wednesday, April 20, 2016


Hi,


It's a well known PHP problem, that exceeding of execution time-out
(max_execution_time) may lead to unexpected crashes.

They occur because PHP may be interrupted in inconsistent state, 
and attempt

to release allocated by request resources leads to failure.

Almost any big site sees these crashes from time to time.


I propose to delay actual request termination until a "safe" point in
interpreter.

Signal handler will just set EG(timed_out) flag.

Interpreter will check this time from time to time (on jumps and 
calls that

may make loops or recursion) and perform the actual termination.

This approach already works in PHP for Windows.


I was thinking about this, checking for things like EG(exception) 
"constantly," a few months ago for another reason...


This is a bit different problem. We can't delay EG(exception) checks. 
I thought about a better way of exception handing but didn't find 
anything usable and portable.


What about instead of adding additional checks in the same place(s) 
in VM, we just limit it to 1 check, for multiple things? Just have 
EG(something_unexpected_to_check), and behind that (or in a 
function, I guess), the actual rare/unexpected thing gets checked: 
timed_out, exception, etc.


Yes, I have the same idea in background. I even wrote: The same 
"interrupt" handling mechanism in the future may be reused for TICK

and signal handling.



It seems Bob had a similar idea in the PR comment, except literally 
using exceptions...



In addition I introduce hard_timeout (default value 2 seconds).

In case the "soft" timeout wasn't handled "safely" in that 2 seconds
(because of long running internal function), PHP process will be 
terminated

without attempt to free any resources.

ZTS build will ignore "hard_timeout" (in the same way as PHP on 
Windows do).



The PR: https://github.com/php/php-src/pull/1876


It removes "exit_on_timeout" ini directive, and introduces 
"hard_timeout"

instead.

Additional checks in VM make 0.5-1% slowdown in term of instruction 
retired

reported by callgrind.


A single check would save those additional instructions and 
branches, and would actually improve things on Windows (since this 
PR doesn't change anything there).


If you or Bob show me a better working solution (or just PoC), I'll 
be only happy with this.


I looked at it; if we had an already existing if (EG(exception)) 
branch there, we could actually save something, but Dmitry put it just 
in jumping ops, where we never have an exception check. (And there we 
need a check as else a while(1) {} would never be timed out - i.e. 
when there are no ops inside which actually do a check_exception) … so 
this EG(something_unexpected_to_check) is even more expensive.
I meant later we may replace check for EG(timed_out) with check for 
EG(something_unexpected_to_check), and then perform additional checks in 
zend_vm_interrupt().


Thanks. Dmitry.



Things would be easy if we could just alter the return addresses of 
the opcode handlers or similar magic, but I doubt that's a very nice 
cross-platform solution...


If you have an even better idea than I do… please show a PoC :-)

Thanks,
Bob


Thanks. Dmitry.




I think we don't need RFC for this. This is a long time desired fix.


The same "interrupt" handling mechanism in the future may be reused 
for TICK

and signal handling.


Thanks. Dmitry.


- Matt

Re: [PHP-DEV] Safe timeout handling

[Dmitry Stogov]

On 04/20/2016 06:24 PM, Matt Wilmas wrote:

Hi Dmitry,

- Original Message -
From: "Dmitry Stogov"
Sent: Wednesday, April 20, 2016


Hi,


It's a well known PHP problem, that exceeding of execution time-out
(max_execution_time) may lead to unexpected crashes.

They occur because PHP may be interrupted in inconsistent state, and 
attempt

to release allocated by request resources leads to failure.

Almost any big site sees these crashes from time to time.


I propose to delay actual request termination until a "safe" point in
interpreter.

Signal handler will just set EG(timed_out) flag.

Interpreter will check this time from time to time (on jumps and 
calls that

may make loops or recursion) and perform the actual termination.

This approach already works in PHP for Windows.


I was thinking about this, checking for things like EG(exception) 
"constantly," a few months ago for another reason...


This is a bit different problem. We can't delay EG(exception) checks. I 
thought about a better way of exception handing but didn't find anything 
usable and portable.


What about instead of adding additional checks in the same place(s) in 
VM, we just limit it to 1 check, for multiple things? Just have 
EG(something_unexpected_to_check), and behind that (or in a function, 
I guess), the actual rare/unexpected thing gets checked: timed_out, 
exception, etc.


Yes, I have the same idea in background. I even wrote: The same 
"interrupt" handling mechanism in the future may be reused for TICK

and signal handling.



It seems Bob had a similar idea in the PR comment, except literally 
using exceptions...



In addition I introduce hard_timeout (default value 2 seconds).

In case the "soft" timeout wasn't handled "safely" in that 2 seconds
(because of long running internal function), PHP process will be 
terminated

without attempt to free any resources.

ZTS build will ignore "hard_timeout" (in the same way as PHP on 
Windows do).



The PR: https://github.com/php/php-src/pull/1876


It removes "exit_on_timeout" ini directive, and introduces 
"hard_timeout"

instead.

Additional checks in VM make 0.5-1% slowdown in term of instruction 
retired

reported by callgrind.


A single check would save those additional instructions and branches, 
and would actually improve things on Windows (since this PR doesn't 
change anything there).


If you or Bob show me a better working solution (or just PoC), I'll be 
only happy with this.


Thanks. Dmitry.




I think we don't need RFC for this. This is a long time desired fix.


The same "interrupt" handling mechanism in the future may be reused 
for TICK

and signal handling.


Thanks. Dmitry.


- Matt



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

Re: [PHP-DEV] [RFC] Nullable Types

[Dmitry Stogov]

What we really miss now, is an ability to define nullable return types.


https://wiki.php.net/rfc/nullable_return_types


I don't care about the same notations for arguments (and everything else), 
because we already may use NULL default value.

However usage of "?" for arguments also may make sense. Someone may like this, 
someone not.


Thanks. Dmitry.


From: guilhermebla...@gmail.com <guilhermebla...@gmail.com>
Sent: Wednesday, April 20, 2016 18:05
To: Lin Yo-An
Cc: Dmitry Stogov; Tom Worster; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types

I read the RFC and I want to highlight why I'll vote -1 on it even before it 
goes to voting.

IMHO, it looks backwards to what the language is progressing. The introduction 
of nullable type hint as a separate notation than a simple type hint makes it 
*very* hard to implement typed properties, factory methods and constructor 
verifications.

Dmitry is even involved in the discussion of having IS_UNDEF until constructor 
ends, then enforcing type hinting at the end of constructor to trigger 
potential invalid instance state. It created a mess in the internal structure 
by creating a 3-state value: uninitialized, absent of value (null) and assigned 
value. All this problem would be solved by merging null into accepted value.
So far the proposed solution there to take a wrong assumption to assume a 
default value based on type defined (like int = 0, string = '', etc), which are 
all potential valid values, leading to unpredictable behavior if a develop 
misses to assign a value to that property.

Sure, people will say that now PHP will require a NullPointerException, PHP is 
turning into Java, or that I don't know what I'm talking about because they 
coded for Amiga and I don't (yes, I've seen that already in this mailing list). 
But the fact is that keeping control of 3-state flags are hard to maintain.

Constructor verifications is actually a completely different subject that 
shouldn't be considered as part of typed properties, but for final properties 
(or whoever other keyword someone think is smarter because *reasons*). It's bad 
to bring this already to typed properties, specially because of its runtime 
performance impact.

Now let's say we move forward with nullable type hint, ignore everything what I 
said and move forward. Congratulations, we just created a language 
inconsistency. Example:

function foo(Bar $bar = null);

Why now I have 2 ways to define a nullable value? Shouldn't this be changed 
into this:

function foo(?Bar $bar);

But of course, changing this would be a BC break and should be left for 
*reasons*. But accepting the absence of value (null) as a valid value, it would 
address the language inconsistency (the current support would be kept, so no BC 
break), and would solve a huge mess that typed properties patch currently needs 
to solve. Ah, and we don't continue into this path of madness where same thing 
have 144 different ways in different areas to be defined.


Regards,

On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An 
<cornelius.h...@gmail.com<mailto:cornelius.h...@gmail.com>> wrote:
On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:

> The grammar is taken from HHVM.
> Using any other would make more mess.
>
I agree



--
Guilherme Blanco
Lead Architect at E-Block

[PHP-DEV] Safe timeout handling

[Dmitry Stogov]

Hi,


It's a well known PHP problem, that exceeding of execution time-out 
(max_execution_time) may lead to unexpected crashes.

They occur because PHP may be interrupted in inconsistent state, and attempt to 
release allocated by request resources leads to failure.

Almost any big site sees these crashes from time to time.


I propose to delay actual request termination until a "safe" point in 
interpreter.

Signal handler will just set EG(timed_out) flag.

Interpreter will check this time from time to time (on jumps and calls that may 
make loops or recursion) and perform the actual termination.

This approach already works in PHP for Windows.


In addition I introduce hard_timeout (default value 2 seconds).

In case the "soft" timeout wasn't handled "safely" in that 2 seconds (because 
of long running internal function), PHP process will be terminated without 
attempt to free any resources.

ZTS build will ignore "hard_timeout" (in the same way as PHP on Windows do).


The PR: https://github.com/php/php-src/pull/1876


It removes "exit_on_timeout" ini directive, and introduces "hard_timeout" 
instead.

Additional checks in VM make 0.5-1% slowdown in term of instruction retired 
reported by callgrind.

I think we don't need RFC for this. This is a long time desired fix.


The same "interrupt" handling mechanism in the future may be reused for TICK 
and signal handling.


Thanks. Dmitry.

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/19/2016 10:53 PM, Stanislav Malyshev wrote:

Hi!


More properly - PHP is done in a way that doesn't allow big data
processing yet :)

LuaJIT may be used for in-kernel packet filtering...

But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language semantics for minuscule gains in
performance. Especially given that banning unset by itself will achieve
nothing - you also have to deal with lots of other ways object can be
initialized.
OK. In my opinion, if something is defined as "int" should be always 
"int". Nor "null" neither "undefined".
This is good for programmers who think like me, for compiler and for 
hardware CPU :)

You have another opinion, and we won't persuade each other.
Lets stop this discussion, because everyone who read already understood 
both point of views.





Run bench.php with CALL and GOTO VM.
You'll see 20-30% performance difference caused by branch miss-prediction.

That's whole VM, not one branch which is never taken.
Yes, this is just an example how branch miss-prediction may affect 
performance.






I think, If we may eliminate checks we should do it (at type-system
design level).

I don't think we really can without introducing some very strange
limitations, like banning unsets or limiting serialization or
introducing special magic methods that are optimized differently, etc.

Personally, I think we can,
but if we can't provide type safety for all cases, we shouldn't try to 
do this for some case, shouldn't name this "typing" and shouldn't 
perform type checks at all.
Lets name this "type annotations" and don't perform run-time type checks 
(like HHVM Hack do).


Thanks. Dmitry.


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

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

[Dmitry Stogov]

It should be possible to do this for functions and simple classes.
Most probably this will require some engine changes, but this is not a big 
problem for major release.
Conditional definition and run-time class inheritance will make significant 
troubles.

Thanks. Dmitry.

From: Lin Yo-An 
Sent: Wednesday, April 13, 2016 18:55
To: internals@lists.php.net
Subject: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

Hi internals,


The javascript engine V8 uses a strategy called "startup snapshot" to
optimize app load time (see
http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more
details)

The approach used by V8 creates a snapshot from heap, so the V8Context
could be reused directly without re-running the bootstraping code.

I think running javascript app in the browser is somehow like we run php
script for each requests where the app bootstrapping code is required to be
executed repeatedly for each request.

Currently, our opcache extension can cache the byte codes, but the byte
codes still need to be executed every time when bootstrapping an app, and
which increases the overhead for each request.

For example, a lot of applications use composer to initialize the class
loader via the statement below:

require "vendor/autoload.php";

The statement above produces thousands of byte code to run, which is to
make an app ready. (If you use vld extension to show the opcodes)

However, if we can support a simple syntax to describe what is doing
"bootstrap", we are able to create a startup snapshot from it.


The proposal here want to introduce some new syntax to optimize app load
time though the below syntax:

bootstrap "vendor/autoload.php";  // caches the context after running
this script.

Or

bootstrap {
   require "vendor/autoload.php";
   // do something else for making app ready
};

And of course, we might detect the bootstrap script automatically without
creating new syntax and opcodes, but I think it's hard to do because PHP
applications can be written by many ways...


Questions


I don't know if this approach is doable or not. Or maybe we can support
this in a separated extension instead of changing the zend core?

Do you guys think it's doable? would you like to share your idea for this?






Best Regards,

Yo-An Lin

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

Re: [PHP-DEV] RFC: Functional Interfaces

[Dmitry Stogov]

On 04/19/2016 05:30 PM, Rowan Collins wrote:

Dmitry Stogov wrote on 19/04/2016 15:12:
I prefer intuitive concepts, that I may use without rereading manual 
again and again.
For this one, I even can't imagine a natural (not over-designed) use 
case. 


The use case that came to my mind is kind of the other way around from 
"syntax sugar for anonymous classes" - providing a contract for what a 
callback should look like. In essence, it's an alternative to 
specifying closure type with a generic-like syntax, as proposed at 
https://wiki.php.net/rfc/callable-types


Say you currently have this:

public function registerCallback(callable $callback) { ... }

You could instead specify what the callback needs to accept and return:

interface EventCallbackInterface {
public function __invoke(Event $event): boolean;
}
public function registerCallback(EventCallbackInterface $callback) { 
... }


Using __invoke as the method name may or may not be a good idea, but 
it interestingly means I don't need to change the code that runs the 
callback, I can just use $callback($some_event); Then if someone wants 
to use a complex object, they can; and if they just want to use a 
closure, it has to meet the contract.


callable-type is much simpler solution for this use-case.
Usage of Interfaces to check function prototypes is a bit tricky, but 
yes, this is a possible use-case.

Do you like to work with framework, that use this trick for every callback?

Thanks. Dmitry.



Regards,



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

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

[Dmitry Stogov]

On 04/19/2016 05:18 PM, Nikita Popov wrote:

On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins  wrote:


Morning Internals,

 Please review the following RFC:

 https://wiki.php.net/rfc/lexical-anon

 A look at the patch from those of you that do that would be good :)


Hey Joe,

The syntax and semantics proposed in this RFC don't sit quite well with me.
Especially the fact that a use($foo) on the class is then used as
$this->foo in methods is non-intuitive to me, as it differs from how the
same syntax behaves on closures. I'd like to suggest an alternative syntax:

$foo = 42;
return new class {
 private $bar = $foo;
 public function getBar() { return $this->bar; }
}


This syntax is definitely better, less magic and more powerful.



That is, allow properties inside the anonymous class to be initialized
based on values from the surrounding scope. This is more explicit (clearly
shows that a property is being created), it allows explicit control over
the visibility and, depending on implementation, might be more flexible
with regards to the values it accepts. It probably doesn't make sense to
restrict this to specific expressions, so all of

return new class {
 private $a = $var;
 private $b = $obj->prop;
 private $d = $obj->prop ?? 'default';
 // ...
}

could be fine.


Is this for anonymous classes only?
Only for property default values or something else?

Also, instead of lexical scoping, we may use generic approach.

return new 

Re: [PHP-DEV] RFC: Functional Interfaces

[Dmitry Stogov]

For me, the proposal is too complex.
I prefer intuitive concepts, that I may use without rereading manual 
again and again.

For this one, I even can't imagine a natural (not over-designed) use case.
But this is my personal opinion, and I may be wrong :)

I'll review the code later.

Thanks. Dmitry.


On 04/19/2016 04:29 PM, Joe Watkins wrote:

> What value?

Yes, shorter, more concise (from the programmers perspective) syntax.

Right now, if you do a lot of work with Closures, you have to verify 
their interface, the value in having the engine do it for you seems 
really obvious.


But also ...

> I thought the same might be implemented through anonymous classes.

An anonymous class cannot be rebound, they are obviously not the same 
thing.


> I didn't take a deep look into the code.

I'll wait until you have, I think :)

Cheers
Joe

On Tue, Apr 19, 2016 at 2:22 PM, Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 04/19/2016 03:52 PM, Joe Watkins wrote:

Oh, it's confusing text in the RFC, using the word "Interface"
... that's meant as a placeholder for InterfaceName.

Cheers
Joe

On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins
<pthre...@pthreads.org <mailto:pthre...@pthreads.org>> wrote:

Morning Dmitry,

  In your example, they will do the same thing.

  Anon classes don't have lexical scope, I have a patch for
that, and an RFC, I'm just tidying it.



OK. so this is not just a syntax sugar, but if you implement
lexical scope for anonymous classes it's going to be sugar. Right?
May be it's better to start from classes first?



  Even when anon classes do have lexical scope, there is
value in being able to implement these kinds of interfaces
using only a function.



What value? just shorter syntax? or anything else?



  The changes to the vm are restricted to a few lines, that's
not seriously a problem, is it !?



I hope no. I didn't understand all details of proposal and I
didn't take a deep look into the code.



  I don't see where I extend closure with an interface ...



I meant new field zend_execute_data *interface in zend_closure
structure.
I thought the same might be implemented through anonymous classes.

Thanks. Dmitry.




  > zend_do_inheritance_ex(type, zend_ce_closure, 1);
  > zend_class_implements(type, 1, interface);

Cheers
    Joe

    On Tue, Apr 19, 2016 at 1:01 PM, Dmitry Stogov
<dmi...@zend.com <mailto:dmi...@zend.com>> wrote:



Are $cb1 and $cb2 going to be the same (do the same)?
Is this just a new syntax sugar, or a really new feature?

According to implementation, I think, you shouldn't
extend "zend_closure" with "interface".
If this is a sugar, lets implement it as a sugar (without
VM changes).

But may be I didn't understand the idea at all :)

Thanks. Dmitry.



From: Joe Watkins <pthre...@pthreads.org
<mailto:pthre...@pthreads.org>>
Sent: Monday, April 18, 2016 13:22
To: PHP internals
Subject: [PHP-DEV] RFC: Functional Interfaces

Morning Internals,

Please review the following RFC:

https://wiki.php.net/rfc/functional-interfaces

An implementation is provided, and is testable on 3v4l.

Review of the implementation from those of you that
do that would be
good :)

Cheers
Joe

Re: [PHP-DEV] RFC: Functional Interfaces

[Dmitry Stogov]

On 04/19/2016 03:52 PM, Joe Watkins wrote:
Oh, it's confusing text in the RFC, using the word "Interface" ... 
that's meant as a placeholder for InterfaceName.


Cheers
Joe

On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins <pthre...@pthreads.org 
<mailto:pthre...@pthreads.org>> wrote:


Morning Dmitry,

  In your example, they will do the same thing.

  Anon classes don't have lexical scope, I have a patch for that,
and an RFC, I'm just tidying it.



OK. so this is not just a syntax sugar, but if you implement lexical 
scope for anonymous classes it's going to be sugar. Right?

May be it's better to start from classes first?



  Even when anon classes do have lexical scope, there is value in
being able to implement these kinds of interfaces using only a
function.



What value? just shorter syntax? or anything else?



  The changes to the vm are restricted to a few lines, that's not
seriously a problem, is it !?



I hope no. I didn't understand all details of proposal and I didn't take 
a deep look into the code.




  I don't see where I extend closure with an interface ...



I meant new field zend_execute_data *interface in zend_closure structure.
I thought the same might be implemented through anonymous classes.

Thanks. Dmitry.



  > zend_do_inheritance_ex(type, zend_ce_closure, 1);
  > zend_class_implements(type, 1, interface);

Cheers
Joe

On Tue, Apr 19, 2016 at 1:01 PM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:



Are $cb1 and $cb2 going to be the same (do the same)?
Is this just a new syntax sugar, or a really new feature?

According to implementation, I think, you shouldn't extend
"zend_closure" with "interface".
If this is a sugar, lets implement it as a sugar (without VM
changes).

But may be I didn't understand the idea at all :)

Thanks. Dmitry.



From: Joe Watkins <pthre...@pthreads.org
<mailto:pthre...@pthreads.org>>
Sent: Monday, April 18, 2016 13:22
To: PHP internals
Subject: [PHP-DEV] RFC: Functional Interfaces

Morning Internals,

Please review the following RFC:

https://wiki.php.net/rfc/functional-interfaces

An implementation is provided, and is testable on 3v4l.

Review of the implementation from those of you that do
that would be
good :)

Cheers
Joe

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

[Dmitry Stogov]

On 04/19/2016 04:09 PM, Levi Morrison wrote:

On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov <dmi...@zend.com> wrote:

Only one note. I would prefer to use "," instead of "|" as a class name 
separator.
Especially if "Union types" are not accepted.
The rest should be fine.

On the other hand if union types is accepted it makes no sense to use "," here.
Right. Lets take a final decision about syntax, after "Unoin Types" 
voting (but before 7.1 release).


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

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

[Dmitry Stogov]

Only one note. I would prefer to use "," instead of "|" as a class name 
separator.
Especially if "Union types" are not accepted.
The rest should be fine.

Thanks. Dmitry.



From: Bronisław Białek 
Sent: Sunday, April 17, 2016 19:51
To: PHP internals
Subject: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Hi Internals,

We've opened the vote on https://wiki.php.net/rfc/multiple-catch
Voting will end on 2015-05-01

--
Regards,
Bronisław Białek.

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

Re: [PHP-DEV] RFC: Functional Interfaces

[Dmitry Stogov]

Are $cb1 and $cb2 going to be the same (do the same)?
Is this just a new syntax sugar, or a really new feature?

According to implementation, I think, you shouldn't extend "zend_closure" with 
"interface".
If this is a sugar, lets implement it as a sugar (without VM changes).

But may be I didn't understand the idea at all :)

Thanks. Dmitry.



From: Joe Watkins 
Sent: Monday, April 18, 2016 13:22
To: PHP internals
Subject: [PHP-DEV] RFC: Functional Interfaces

Morning Internals,

Please review the following RFC:

https://wiki.php.net/rfc/functional-interfaces

An implementation is provided, and is testable on 3v4l.

Review of the implementation from those of you that do that would be
good :)

Cheers
Joe

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/18/2016 09:37 PM, Stanislav Malyshev wrote:

Hi!


right.
I don't see any reasons for types, if they are not guaranteed anyway.

Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.

They guarantee the type of argument on function entry.




This depends on use case.
Just imagine matrix multiplication (or something similar).
Few additional instructions would decrease the speed significantly.

I think this is a very narrow use case. If somebody does large data
processing (like large matrix multiplication) in pure PHP, they are
doing it wrong anyway.
More properly - PHP is done in a way that doesn't allow big data 
processing yet :)


LuaJIT may be used for in-kernel packet filtering...


  So trying to optimize for their use case I think
is not a high priority. I would say for any typical PHP app cost of one
unexpected branch is negligible.

One is not, but 100 matters.
Run bench.php with CALL and GOTO VM.
You'll see 20-30% performance difference caused by branch miss-prediction.

Now think about JIT, and "code-bloat" caused by additional type checks.

I think, If we may eliminate checks we should do it (at type-system 
design level).


Thanks. Dmitry.


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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/15/2016 11:07 PM, Stanislav Malyshev wrote:

Hi!


In most cases we avoid IS_UNDEF checks, verifying the most probable expected 
types first.

But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also track the variable after fetching?

In any case, to use this without any UNDEF/NULL checks, you need to be
absolutely sure the value is always initialized to the right type. I.e.
if you have a class like:

class Point {
public int $x;
public int $y;
}

Then you need to request the following:

- Always require the default. Otherwise, even in ctor, you could use $x
in expression before it is initialized and assume it is long where it is
in fact null. For many classes, the default would be completely
arbitrary (e.g. 0 is not always a natural default).

- Somehow handle unserialization in order to ensure what is put into $x
is always int. Moreover, unserialization may involved __wakeup which
sets up some properties, and before those properties are set up, how do
we ensure they have the right types without checking? Unserialize data
can contain anything, we had enough trouble with this unserializing
internal objects.

- Ensure that no extension manually creates objects without properly
initializing the typed variables. Extensions can easily create objects
right now and they can put anything in the object's hashes, can we trust
that every extension does the right thing?


right.
I don't see any reasons for types, if they are not guaranteed anyway.



The cost of getting any of these wrong may be high - it's not just
getting weird conversion, if the engine assumes something is LONG or
STRING without checking, it can be memory corruption or even RCE if
we're particularly unlucky.

So I am very skeptical right now about the possibility of making
optimizations based on using property type without checking based on
just declared type in the class.

then, why do we need them at all?



Additionally, if we *do* allow the possibility of NULL/UNDEF, the
performance loss would be quite minimal - we could still do
specialization based on assumed type, but then just insert something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
   op1 = _as_long;
}

for types that have natural default for longs, or something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
zend_error("Undefined value where object is expected");
}

if we expected object. The cost of one branch that is almost never taken
should be quite minimal, and we avoid a lot of trouble on the way.


This depends on use case.
Just imagine matrix multiplication (or something similar).
Few additional instructions would decrease the speed significantly.

Thanks. Dmitry.






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

Re: [PHP-DEV] [RFC] Nullable Types

[Dmitry Stogov]

The grammar is taken from HHVM.
Using any other would make more mess.

Thanks. Dmitry.


From: Tom Worster <f...@thefsb.org>
Sent: Saturday, April 16, 2016 04:54
To: Dmitry Stogov; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types

On 4/15/16 1:58 PM, Dmitry Stogov wrote:
> A week ago, I actually wrote my own RFC 
> https://wiki.php.net/rfc/nullable_return_types

You proposed the ?Something grammar. With ?: and ?? appearing in recent
PHP and proposals for ??= if not ?:= and now this, I feel we're heading
to regex hell :p

Tom

> but didn't push it for discussion in favor of Levi's  nullable_type RFC (they 
> are almost the same).


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

Re: [PHP-DEV] [RFC] Nullable Types

[Dmitry Stogov]

A week ago, I actually wrote my own RFC 
https://wiki.php.net/rfc/nullable_return_types
but didn't push it for discussion in favor of Levi's  nullable_type RFC (they 
are almost the same).

I'm sure, union types bring too many conceptual and implementation questions, 
and I even don't speak abut intersections.

Thanks. Dmitry.

From: Tom Worster <f...@thefsb.org>
Sent: Friday, April 15, 2016 20:17
To: Dmitry Stogov; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types

On 4/14/16 3:50 AM, Dmitry Stogov wrote:

> The up to date implementation for return-type-hints may be found at
> https://github.com/php/php-src/pull/1851/files

Splendid!

Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1].

Tom

[1] https://wiki.php.net/rfc/nullable_returns


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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

Stas, you have to look into "master" branch code.

In most cases we avoid IS_UNDEF checks, verifying the most probable expected 
types first.

ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2, *result;

op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
fast_long_add_function(result, op1, op2);
ZEND_VM_NEXT_OPCODE();

We also have specialized handlers that don't check for types at all (they are 
used, if we know types at optimization time).

ZEND_VM_TYPE_SPEC_HANDLER(ZEND_ADD, (res_info == MAY_BE_LONG && op1_info == 
MAY_BE_LONG && op2_info == MAY_BE_LONG), ZEND_ADD_LONG_NO_OVERFLOW, 
CONST|TMPVARCV, CONST|TMPVARCV, SPEC(NO_CONST_CONST,COMMUTATIVE))
{
USE_OPLINE
zval *op1, *op2, *result;

op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
result = EX_VAR(opline->result.var);
ZVAL_LONG(result, Z_LVAL_P(op1) + Z_LVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}

The second technique won't work for typed properties if they might be turned 
into IS_UNDEF. 

Thanks. Dmitry. 


From: Stanislav Malyshev <smalys...@gmail.com>
Sent: Thursday, April 14, 2016 20:26
To: Dmitry Stogov; Joe Watkins
Cc: internals; Zeev Suraski; Nikita Popov
Subject: Re: [PHP-DEV] Re: Typed properties patch

Hi!

> I didn't understand.
> Of course we keep a class definition, where the type of property "$a" -
> IS_LONG, but the actual value of "$a" may become IS_UNDEF.

What I'm saying is maybe it's fine.

> In PHP-7 we check for IS_LONG without type hint.
> With type hint and ability to unset(), we will have to check for IS_LONG
> anyway.

Well, we'd have to check for IS_UNDEF, but we won't have to choose
between IS_LONG, IS_OBJECT and IS_RESOURCE.

> So type hinting won't improve reading performance, but writing is going
> to be slower, because we have to perform type check.
> So even theoretically this approach couldn't make any improvement.

Maybe I misunderstand what performance improvements there are. Do we do
different things when reading a variable depending on type? I thought
it's for *operations* with variables, but for just reading them it
doesn't matter. For operations, we could have instead of function
handling all types just function handling IS_LONG and a small check for
UNDEF inside.

I think it is mych better than a weird concept of non-unsettable variable.
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/13/2016 10:31 PM, Stanislav Malyshev wrote:

Hi!


Because if you unset() a property it's type is not guaranteed anymore.

Can't we fix it? I mean, when we unset property on an object, we're
still keeping the definition in the class, right? Can't we use it?

I didn't understand.
Of course we keep a class definition, where the type of property "$a" - 
IS_LONG, but the actual value of "$a" may become IS_UNDEF.



x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use
optimized code */

Can't we assume $a->x is still "int" here in a way - I mean, we'd still
have to allow for the possibility of null, but if we say that any one
could be null it's just one easy check, so it won't hurt performance too
much, not?

In PHP-7 we check for IS_LONG without type hint.
With type hint and ability to unset(), we will have to check for IS_LONG 
anyway.
So type hinting won't improve reading performance, but writing is going 
to be slower, because we have to perform type check.

So even theoretically this approach couldn't make any improvement.

Thanks. Dmitry.







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

Re: [PHP-DEV] [RFC] Union Types

[Dmitry Stogov]

The RFC doesn't say anything about support for multiple class names.

function foo(A|B|C $x)

Support for multiple classes would lead to complex implementation.

Thanks. Dmitry. 


From: Levi Morrison 
Sent: Thursday, April 14, 2016 06:46
To: internals
Subject: [PHP-DEV] [RFC] Union Types

As alluded to in an earlier email today[1] I am now moving the Union
Types RFC[2] to the discussion phase. The short summary of the RFC is
that it permits a type declaration to be one of several enumerated
types. For example, this is a potential signature for a multi-type map
routine:

function map(callable $f, Array | Traversable $iterable);

The second parameter `$iterable` is required to be of type Array or
Traversable - any other type will error.

I look forward to a helpful and meaningful discussion!

  [1]: http://news.php.net/php.internals/92252
  [2]: https://wiki.php.net/rfc/union_types

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


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

Re: [PHP-DEV] [RFC] Nullable Types

[Dmitry Stogov]

On 04/14/2016 06:42 AM, Levi Morrison wrote:

As alluded to in an earlier email today[1] I am now moving the
Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC
proposes syntax for declaring a type to alternatively be null.

+1

The up to date implementation for return-type-hints may be found at 
https://github.com/php/php-src/pull/1851/files

Implementation for argument-type-hints is really not a problem



There is a decision that needs to be made: does the question mark go
before or after the type name?

 function (?Foo $foo);
 function (Foo? $foo);

There are precedents in several languages for each position. Some
relevant issues to where the question mark goes are noted in the
RFC[3].


It's better to use ? position before the type, to reduce fragmentation 
with HHVM.


Thanks. Dmitry.



I look forward to a helpful and meaningful discussion!

   [1]: http://news.php.net/php.internals/92252
   [2]: https://wiki.php.net/rfc/nullable_types
   [3]: https://wiki.php.net/rfc/nullable_types#position_of




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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

We are talking only about unsettling of typed properties



From: guilhermebla...@gmail.com <guilhermebla...@gmail.com>
Sent: Wednesday, April 13, 2016 16:08
To: Dmitry Stogov
Cc: Nikita Popov; Stanislav Malyshev; internals; Joe Watkins; Zeev Suraski
Subject: Re: [PHP-DEV] Re: Typed properties patch


Hi,

Unsetting properties is used by a range of libraries I am aware of, including 
Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter would 
not only address the unsetting hack, but also allow read only properties (final 
properties). IMHO, we should look back at that implementation (it was mainly 
rejected because of the patch complexity (not the idea), which would kill two 
birds with one stone.

Cheers,

On Apr 13, 2016 2:59 AM, "Dmitry Stogov" 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:


On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:
Hi!

 Thanks for your time reviewing the patch, appreciated.

 > 1) nullable properties

 I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.
I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.

 > 3) disable unset
This sounds very weird. Why I would suddenly unable to unset a property?

Because if you unset() a property it's type is not guaranteed anymore.

x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use optimized code 
*/
?>

As we can't be sure where the property may be unset(), we won't be able to use 
optimized code at all (even in first place).

Thanks. Dmitry.





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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:

Hi!


 Thanks for your time reviewing the patch, appreciated.

 > 1) nullable properties

 I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.

I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.


 > 3) disable unset

This sounds very weird. Why I would suddenly unable to unset a property?


Because if you unset() a property it's type is not guaranteed anymore.

x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use 
optimized code */

?>

As we can't be sure where the property may be unset(), we won't be able 
to use optimized code at all (even in first place).


Thanks. Dmitry.






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

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

I think, It's going to be a part of opcache.

Today, all PHP processes use shared bytecode, with JIT we will in addition 
share the native code.


Thanks. Dmitry.



From: Lin Yo-An <cornelius.h...@gmail.com>
Sent: Monday, April 11, 2016 19:04
To: Dmitry Stogov
Cc: Xinchen Hui; Nikita Popov; Bob Weinand; Joe Watkins; internals
Subject: Re: Object getter method optimization



On Mon, Apr 11, 2016 at 11:53 PM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:

We consider, possibility of moving the whole Optimizer into Zend, but it won't 
change a lot, because expensive optimization make sense only with opcache (when 
script is optimized once and executed many times).

Do you (or the team?) prefer to keep the JIT implementation as an extension or 
integrate the JIT implementation into the Zend core?


Thanks, Yo-An

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

Hi Yo-An

On 04/11/2016 02:54 PM, Lin Yo-An wrote:

Hi Dmitry,

How's it going?

I traversed the code of opcache extension, and just found the 
FUNC_INFO related macros.  I guess the accessor information is more 
like an entry that should be put in the function info.


That, FUNC_INFO is available only during optimization (it's especially 
used in inter-procedure data-flow pass).
Or... maybe we shall move the function info related functions into the 
core? since we might have some optimization based on the function info 
instead of optimizing opcode only in the future.
We consider, possibility of moving the whole Optimizer into Zend, but it 
won't change a lot, because expensive optimization make sense only with 
opcache (when script is optimized once and executed many times).




And I think the function info we pre-processed in the compile-time 
would help JIT to compile the opcode a lot.
Of course. Actually, the new optimization passes introduced in "master" 
branch came from our zend-jit project and reused to generate LLVM code.


By the way, would you mind to let me know the plan of implementing the 
JIT compilation in PHP? I saw your zend-jit branch is using LLVM as 
the backend.
We don't have special plans yet. We are going to work on JIT later, and 
now we mainly work on interpretative optimizations.
Once we start JIT, it's going to be much difficult to change something 
in VM...


In my experience, LLVM compiles large code a lot of slower.  what do 
you think of using DynASM as the JIT backend?

Right. LLVM is not suitable for JIT. It's a compiler without front-end part.
We will probably go with DynASM from LuaJIT, Low Level Interpreter from 
WebKit or our own similar approach.


V8 compiles ast nodes into native code directly without 
interpreting/translating the op codes, I don't know if it's a good 
approach to try. your thoughts?
In my experience, this approach doesn't work well especially with big 
PHP applications.


Thanks. Dmitry.


Cheers, Yo-An

Re: [PHP-DEV] Typed properties patch

[Dmitry Stogov]

On 04/07/2016 08:55 PM, Fleshgrinder wrote:

On 4/7/2016 3:55 PM, Dmitry Stogov wrote:

On 04/07/2016 03:44 PM, Bob Weinand wrote:

Am 6.4.2016 um 10:45 schrieb Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>>:
1) While parameters allow null to be accepted as the default value,
null is never a valid value for a typed property.


I think we must have a way to make properties explicitly nullable.
Otherwise we won't be able to define even simple binary tree...


class Node {


   public Node $left = null;

   public Node $right = null;

}


Eventually that, but I honestly would prefer to be more explicit with
a typed union

public Node | null $left;

This is not a subject of this RFC. This is about "union types" vs
"nullable types".


Actually this is not true because an union type with null is the same as
a nullable type.

 class Node {
 public Node? $left;
 public Node|null $right;
 }

Both definitions are equivalent and allow the compiler to reason and
ensure type safety. Using the null assignment as you propose in your
example is not possible as Andrea Faulds pointed out to me and where she
is completely right. Simply because it makes it impossible for you to
have another default value.

Today, PHP works with arguments in this way.
If we decide to enable nullable "?" syntax and/or "union types" we will 
have to use them for properties as well.
but for now, we don't have anything accepted yet, and we are going to 
push both RFC on next week.




 class StupidExample {
 private int? $x = 42;

 public function setX(int? $x = 42) {
 $this->x = $x;
 }
 }

 $o = new StupidExample();
 $o->setX(null);

Note how the nullable (union null) type is much more useful than the
current implementation in PHP.


I don't see a lot of use cases, but it's not a problem to implement this.
Actually the implementation was proposed more than a year ago.

https://wiki.php.net/rfc/nullable_types

Thanks. Dmitry.



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

Re: [PHP-DEV] Typed properties patch

[Dmitry Stogov]

On 04/07/2016 03:44 PM, Bob Weinand wrote:

Hey,

Am 6.4.2016 um 10:45 schrieb Dmitry Stogov <dmi...@zend.com 
<mailto:dmi...@zend.com>>:


Hi Jow,


First of all, I appreciate the amount of effort you already invested 
into this idea.


Anyway, I still don't agree with the following terms of RFC and 
corresponding implementation:



1) While parameters allow null to be accepted as the default value, 
null is never a valid value for a typed property.



I think we must have a way to make properties explicitly nullable. 
Otherwise we won't be able to define even simple binary tree...



class Node {


  public Node $left = null;

  public Node $right = null;

}



Eventually that, but I honestly would prefer to be more explicit with 
a typed union


public Node | null $left;


This is not a subject of this RFC. This is about "union types" vs 
"nullable types".




2) The implementation will raise an exception where a typed property 
is accessed before being initialized: <https://3v4l.org/cVkcj/rfc#tabs>



This makes unnecessary complication, and opens thousands 
possibilities to cheat the engine.



class A {

  public int $x;

}

$a = new A;

var_dump($a->x++); // prints NULL (according to RFC, this should 
raise Exception)



I propose to initialize typed properties with the value of 
corresponding type (if default value is omitted).


boolean => false

int => 0

double => 0.0

string => ""

array => []

object, resource, callable => null


Actually, I propose implicit default values if they are not specified.

This will always guarantee the type and eliminate run-time checks on 
read.




The things being pre-initialized is quite defeating the purpose.
It’s possibly not to easy from an engine perspective, but it is the 
safest thing to do from a type systems perspective.


Also, it is creating useful invariants that a value cannot be null 
(also for optimizer).
Default values for scalars and arrays obviously work, but still, they 
will hide bugs if you forgot to assign a property.


3) It is possible to unset typed properties, and return them to the 
same state as a property that was never set.



This mean that properties types are not guaranteed, and 
Optimizer/Compilers/JIT won't be able to generate the best code 
performing type check on every read.


I would prefer to disable unset() of typed properties.



Property types are guaranteed,

Check the patch. ZEND_FETCH_OBJ_R opcode.
it will just throw an exception when used (it’s a branch which is 
never used, thus relatively cheap). Also that pretty much conflicts 
with your point 2) where you propose null as a default value, 
enforcing a hard type check (which won’t be easy to predict for branch 
predictors).


I don't propose NULL to be a default value. I propose to allow nullable 
properties, in the same way as arguments (only for data that really need 
this).
So "public int $a;" is always going to be "int", nor NULL or UNDEF. And 
you won't need to endlessly check it for is UNDEF.




4) Checking the type of a zval is an extremely cheap operation, there 
may be some very minor performance impact only when typed properties 
are used.



The patch makes some slowdown even if typed properties are not used 
(0.5% more instruction retired on 100 requests to Wordpress according 
to callgrind)




Feel free to optimize it, but possibly we’ll get much more gain than 
0.5% on projects which are going to heavily use it.


This "possibly" makes my cry :(
I'm sure, this will make only slow-down.

Just try to add arg/return type hints to bench.php and see the result.

5) In principle, knowing the type of a variable in advance allows you 
to make optimizations, and in the long term, there is good reason to 
think that typed properties will allow us to improve performance.



This is an optimistic assumption


For now typed-parameters make slowdown except of expected speedup, 
properties are not going to change this.




Actually the type of property may make some gain only if we know the 
type of object and its definition at compile-time, but in most cases 
we do't know the class definition, because definition and usage are 
in different PHP scripts.


Especially with (2) and (3), even if we know type of object and 
property, we'll still have to check if property is initialised on 
each usage.




A lot of optimizable code is inside the classes themselves though 
(private properties). I don’t guess it’s too optimistic? With typed 
properties and typed input vars, computing functions will be very 
optimizable I guess.


don't guess, try and prove!

Also regarding not-null properties, we may have to check the type of 
the property only once for the whole method instead of on every access 
inside that method.




no. because it may be unset() or reassigned.

Thanks. Dmitry.


Bob


Thanks. Dmitry.


-

[PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

Hi Jow,


First of all, I appreciate the amount of effort you already invested into this 
idea.

Anyway, I still don't agree with the following terms of RFC and corresponding 
implementation:


1) While parameters allow null to be accepted as the default value, null is 
never a valid value for a typed property.


I think we must have a way to make properties explicitly nullable. Otherwise we 
won't be able to define even simple binary tree...


class Node {

  public Node $left = null;

  public Node $right = null;

}


2) The implementation will raise an exception where a typed property is 
accessed before being initialized:<https://3v4l.org/cVkcj/rfc#tabs>


This makes unnecessary complication, and opens thousands possibilities to cheat 
the engine.


class A {

  public int $x;

}

$a = new A;

var_dump($a->x++); // prints NULL (according to RFC, this should raise 
Exception)


I propose to initialize typed properties with the value of corresponding type 
(if default value is omitted).

boolean => false

int => 0

double => 0.0

string => ""

array => []

object, resource, callable => null


Actually, I propose implicit default values if they are not specified.

This will always guarantee the type and eliminate run-time checks on read.


3) It is possible to unset typed properties, and return them to the same state 
as a property that was never set.


This mean that properties types are not guaranteed, and Optimizer/Compilers/JIT 
won't be able to generate the best code performing type check on every read.

I would prefer to disable unset() of typed properties.


4) Checking the type of a zval is an extremely cheap operation, there may be 
some very minor performance impact only when typed properties are used.


The patch makes some slowdown even if typed properties are not used (0.5% more 
instruction retired on 100 requests to Wordpress according to callgrind)


5) In principle, knowing the type of a variable in advance allows you to make 
optimizations, and in the long term, there is good reason to think that typed 
properties will allow us to improve performance.


This is an optimistic assumption []

For now typed-parameters make slowdown except of expected speedup, properties 
are not going to change this.


Actually the type of property may make some gain only if we know the type of 
object and its definition at compile-time, but in most cases we do't know the 
class definition, because definition and usage are in different PHP scripts.

Especially with (2) and (3), even if we know type of object and property, we'll 
still have to check if property is initialised on each usage.


Thanks. Dmitry.


________
From: Dmitry Stogov
Sent: Wednesday, April 6, 2016 10:32
To: Joe Watkins
Subject: Typed properties patch


Ho Joe,


I see some tests failures (SIGSEGV)


> Test typed properties float widen at runtime 
> [Zend/tests/type_declarations/typed_properties_027.phpt]
> Test typed properties respect strict types (off) 
> [Zend/tests/type_declarations/typed_properties_028.phpt]
> Test typed properties unset __get magical magic 
> [Zend/tests/type_declarations/typed_properties_030.phpt]


valgrind shows problems on every 4-rd test at Zend/tests (454 of 1668 tests), 
but it seems like a single problem


$ cat ../Zend/tests/add_002.mem
==26053== Conditional jump or move depends on uninitialised value(s)
==26053==at 0x8627895: _zend_object_has_type_hints (zend_execute.h:367)
==26053==by 0x8629098: zend_std_write_property (zend_object_handlers.c:674)
==26053==by 0x85FA1B5: zend_update_property (zend_API.c:3894)
==26053==by 0x85FA38E: zend_update_property_string (zend_API.c:3952)
==26053==by 0x860F8DB: zend_default_exception_new_ex (zend_exceptions.c:222)
==26053==by 0x860F96F: zend_default_exception_new (zend_exceptions.c:236)
==26053==by 0x85F347E: _object_and_properties_init (zend_API.c:1303)
==26053==by 0x85F34B5: _object_init_ex (zend_API.c:1311)
==26053==by 0x86124F4: zend_throw_exception (zend_exceptions.c:881)
==26053==by 0x85EF256: zend_throw_error (zend.c:1316)
==26053==by 0x85E4622: add_function (zend_operators.c:969)
==26053==by 0x868824E: ZEND_ADD_SPEC_CV_CV_HANDLER (zend_vm_execute.h:44246)


Thanks. Dmitry.

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

did you see my patch? It already uses run_time_cache of calling op_array to get 
getter property offset.


It's also possible to "allocate" slots in "run_time_cache" of caller op_array 
at compile_time, increasing op_array->cache_size. (see zend_compile.c), but I 
don't see a big reason to do it.


Thanks. Dmitry.



From: Lin Yo-An <cornelius.h...@gmail.com>
Sent: Tuesday, April 5, 2016 17:32
To: Dmitry Stogov
Cc: Xinchen Hui; Nikita Popov; Bob Weinand; Joe Watkins; internals
Subject: Re: Object getter method optimization

On Tue, Apr 5, 2016 at 10:14 PM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:

I think, op_array->type and op_array->fn_flags can't be reused.

Also, usage of op_array->run_time_cache is safer (I remember, I saw some 
SIGSEGV with your patch and opcache.protect_memory=1)

Got it.Does run_time_cache vary when caller is different? maybe I can use 
the first 2 bytes for the accessor information.

Cheers, Yo-An

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

I think, op_array->type and op_array->fn_flags can't be reused.

Also, usage of op_array->run_time_cache is safer (I remember, I saw some 
SIGSEGV with your patch and opcache.protect_memory=1)


Most probably, I'll able to return to this idea only at the end of the week or 
even on next week.


Thanks. Dmitry.



From: Lin Yo-An <cornelius.h...@gmail.com>
Sent: Tuesday, April 5, 2016 17:00
To: Dmitry Stogov
Cc: Xinchen Hui; Nikita Popov; Bob Weinand; Joe Watkins; internals
Subject: Re: Object getter method optimization

Hi Dmitry,


Glad to hear your news, I just checked your patch and I like the approach 
you've done. :]

I'm also still working on this idea this week, the const value accessor support 
was just added today.  And I guess we may also support setters in the future 
(if possible)

my thought is:

- I think the getter optimization is useful since getter methods are heavily 
used in a lot of application like Drupal (like hundreds)

- If we could produce more information in compile-time, we can reduce more 
runtime cost when executing the opcode handler. This way, we can reduce the 
impact to the overall performance.

- I found the first two bytes in zend_op_array produces a 2 bytes room on 32bit 
machine and even more on 64bit machine because the memory alignment (not sure 
if it could be optimzed when memory alignment optimization is not enabled with 
gcc)


My first attempt was to add a new flag in op_array->type, however it's already 
full, all bits are used currently.

I think we can either extend the op_array type to uint32 or just add a new 
zend_uchar field to save the information (from the 2 bytes room). And using 
cache slot to save the property offset information.

This field will be not only for simple getters, but also for simple setters and 
functions return const or return values that are simplified to scalar value.

Your thoughts?



Cheers, Yo-An









On Tue, Apr 5, 2016 at 7:29 PM, Dmitry Stogov 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:

Hi Yo-An Lin,


I spent few hours working on your idea and came to the following path.


https://gist.github.com/dstogov/2221ffc21ac16311c958a4830dbcee0f


I tried to keep binary compatibility, minimize run-time checks overhead and fix 
related problems and leaks.

BTW I'm not sure, if I like the patch even in this state.


The patch significantly speed-ups getters (more than 2 times) in small cost for 
all other methods, but the final effect on application may be negative.

Of course, we may add specialized opcode for INIT_METHOD_CALL without 
arguments, that would almost completely eliminate overhead.


Anyway, I like to listen opinions:

- if we should include such optimizations?

- do you see any other applications to similar optimizations?


Thanks. Dmitry.



From: Lin Yo-An <cornelius.h...@gmail.com<mailto:cornelius.h...@gmail.com>>
Sent: Sunday, April 3, 2016 11:10
To: Xinchen Hui
Cc: Dmitry Stogov; internals; Nikita Popov
Subject: Re: Object getter method optimization

I submitted the new benchmark result here:

Benchmark Result
Getter Method Only

https://gist.github.com/8cd230a5601cbe38439661adf3caca0d

Without getter optimization (3 runs):
151.0169506073ms

With getter optimization (3 runs)
39.201021194458ms

Template Engine Benchmark

https://gist.github.com/a23cf294dfcf74683b8f02d93a47bc5b

With getter optimization:
1118ms

Without getter optimization:
1235ms

Affect

Other Microbench result: 
https://gist.github.com/c9s/0273ac21631562724cabf86c42e86e32

On Sat, Apr 2, 2016 at 11:29 AM, Lin Yo-An 
<cornelius.h...@gmail.com<mailto:cornelius.h...@gmail.com>> wrote:
Hi Xinchen Hui,

The magic get method is not being optimized. This optimization only focuses on 
simple getter, which is used in a lot of OO-based appoications like Symfony or 
Drupal.


Hi Dimitry,

Thanks for reviewing the code, comments are helpful. :) could you explain a 
little bit of how runtime_cache_slot works?

 I think adding the property_offset in op_array is kinda like a workaround for 
POC, and I want to remove it from op_array.


Cheers, Yo-An


Xinchen Hui <larue...@php.net<mailto:larue...@php.net>> 於 2016年4月1日 星期五寫道：

Hey:

On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@gmail.com> wrote:
Hi Dmitry, Nikita, Andrea


My implementation now is able to get the property offset and fetch object 
property directly without invoking zend_std_read_property and pushing new call 
frame onto the stack.

The current behavior:

1. In compile-time, the pass_two() function now marks the getter functions in 
op_array.accessor.type

2. When Zend Engine first time attempt to read the property, it saves the 
property offset in the accessor field and mark the method as a "getter".
I am not sure if I understand you correctly, but.. have you consider this case?

a;
} else {
return $this->b;

Re: [PHP-DEV] RETURN micro optimization

[Dmitry Stogov]

On 04/05/2016 12:04 PM, Derick Rethans wrote:

On Tue, 5 Apr 2016, Dmitry Stogov wrote:


I propose a micro optimization for RETURN statement.

Currently "return $x" increments reference counter of $x, then in
zend_leave_helper() we perform zval_ptr_dtor() on the same $x.

The patch sets the original value of $x to null in first place, so
zval_ptr_dtor() is not going to be called.

https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40

the performance impact is invisible (0.1% less instruction retired on
Wordpress).

It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably
not a big deal.

BTW: this change may affect debuggers in some other way.

I'd like to know why this breaks before saying something. It'd be a PITA
if this micro optimisation wouldn't actually do a lot performance wise,
but makes some debugging not possible.

Actually, the patch has a bug.
It doesn't take into account that "return $x;" might be used in global 
scope.

Setting $x to NULL in this case isn't right, of course.

Introducing another check would probably negate the effect of 
micro-optimization.


So, ignore this for now, and sorry for noise.

Thanks. Dmitry.




cheers,
Derick



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