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

[Pierrick Charron]

On 22 April 2016 at 11:39, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  wrote:
>
> >
> >
> > 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.
> >
>
>
> 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
> <> 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;
>
> <>
> 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"
>   }
> }
>

+1


>
>
> >
> > 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 \ReflectionClas("Foo");
> $reflMethod = $reflClass->getMethod("bar");
> $reflParameter = $reflMethod->getParameters()[0];
>
> var_dump($reflParameter->getAttributes());
>
>
> >
> >
> >
> > 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.

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

[Larry Garfield]

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

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  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;

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

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

<>
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.)


--
--Larry Garfield


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

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

[guilhermebla...@gmail.com]

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov  wrote:

>
>
> 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.
>


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
<> 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;

<>
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"
  }
}


>
> 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 \ReflectionClas("Foo");
$reflMethod = $reflClass->getMethod("bar");
$reflParameter = $reflMethod->getParameters()[0];

var_dump($reflParameter->getAttributes());


>
>
>
> 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 

Re: [PHP-DEV][RFC] Callable Types

[Nikita Nefedov]

On Fri, 22 Apr 2016 07:12:13 +0300, Marcio Almada   
wrote:



Hello everyone,

We just completed the draft for the "Callable Types" RFC. This RFC has  
been
recently mentioned during other type related threads on this mailing  
list,

so it feels to be the right time to put the proposal in context:

The proposal is at https://wiki.php.net/rfc/callable-types

The W.I.P patch is available for testing through http://3v4l.org under  
the

RFC tab.

We count with your detailed feedback and insights. Let's have a nice,
respectful and
constructive conversation about the RFC and work on possible  
improvements!


Thanks
Nikita Nefedov
Márcio Almada


Hello internals,

We're still having a hard time finding a proper format for error message
about incompatible callable being passed.

Right now it looks like this:

Uncaught TypeError: Argument 3 passed to reduce() must be callable of  
compliant signature: callable(integer, integer): integer, callable($a, $b,  
$c) given, called in ...


Although it goes in the fashion with all other TypeErrors but it's
obviously very cryptic and it will be hard to read for human.

One of the alternatives Marcio proposed was:

Uncaught TypeError: Argument 3 passed to reduce() must be compliant  
with callable(integer, integer): integer, incompatible callable($a, $b,  
$c) received, called in ...


This is remarkably more readable but if you have any suggestions you're  
welcome.
Actually I think other type errors are not very readable as well, take  
f.e.:


Argument 1 passed to foo() must be an instance of string, boolean given

The fact that `string` and `boolean` are separated by only one comma,
and the way `boolean given` is worded (verb after noun) makes it harder
to read. So maybe we could reconsider type error messages and change them
to something more user-friendly, if there's support for this idea...

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

Re: [PHP-DEV][RFC] Callable Types

[Rowan Collins]

Aaron Piotrowski wrote on 22/04/2016 15:56:

While this is somewhat off-topic of this particular RFC, since we can already 
do general type-aliasing with `use`,

use SomeFoo as Foo;

perhaps similar syntax could be used for type expressions, eliminating the need 
for a new keyword.

use callable(int, int): int as IntReducer;

use array | Traversable as Iterable;


The problem with that is that you might want to export (and then import) 
a type definition:


namespace MyPackage\Types {
type Foo as \Symfony\Bar | \Zend\FooBar;
}

namespace Other {
use \MyPackage\Types\Foo as FooType;
}

That would become terrible confusing if you overloaded the "use" keyword.

Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV][RFC] Callable Types

[Rowan Collins]

Levi Morrison wrote on 22/04/2016 15:39:

It would also allow for a general type-aliasing mechanism for single
names. This feature has been asked for in the past but I can't
remember the use-cases so this example is not very good:


One use I've seen is for making the "semantic type" of a scalar more 
obvious. I'd quite like to be able to do this:


type timestamp = int;
function format_date(timestamp $foo) { ... }

Any integer is a valid Unix timestamp, so you don't even need domain 
types in this case, although those would be even better:


type age = int { min: 0 };
type day_of_month = int { min: 1; max: 31 };

Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV][RFC] Callable Types

[Aaron Piotrowski]

Hi!

> On Apr 22, 2016, at 9:39 AM, Levi Morrison  wrote:
> 
>> Not much else to say, the syntax reads a bit weird/heavy being all in-line
>> with the function signature but at the same time I can't imagine how else it
>> would work that would be any better.
> 
> As mentioned on Reddit and in the future scope section of union types,
> we may want to introduce named type expressions:
> 
>type IntReducer = callable(int, int): int;
> 
> Which would also allow unions (if passed, of course):
> 
>type Iterable = Array | Traversable;
> 
> It would also allow for a general type-aliasing mechanism for single
> names. This feature has been asked for in the past but I can't
> remember the use-cases so this example is not very good:
> 
>type Foo = SomeFoo;
> 
> Then we just use the names where we would have put the expressions:
> 
>function reduce(int $a, int $b, IntReducer $reducer): int {
>return $reducer($a, $b);
>}
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

While this is somewhat off-topic of this particular RFC, since we can already 
do general type-aliasing with `use`,

use SomeFoo as Foo;

perhaps similar syntax could be used for type expressions, eliminating the need 
for a new keyword.

use callable(int, int): int as IntReducer;

use array | Traversable as Iterable;

Cheers!

Aaron Piotrowski
@trowski2002
trowski.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.1 roadmap

[Pierre Joye]

On Apr 22, 2016 8:42 PM, "Ferenc Kovacs"  wrote:
>
> co-RM can simply mean "one of the two RMs", and emphasize that somebody
> would volunteer to take the role but not being comfortable to doing it
> alone so I think we are on the same page.

Exactly. And I am convinced Davey and Anatol will come along together for
this release very well.

> On Fri, Apr 22, 2016 at 2:50 PM, Julien Pauli  wrote:
>
> > On Fri, Apr 22, 2016 at 5:03 AM, Davey Shafik  wrote:
> > > I'd interested in co-RMing 7.1 if someone else wants to step up also?
> >
> > Hi.
> >
> > The Co-RM is the version-1 RM, so it will be Anatol, RM of 7.0.
> > We are looking for a "master" RM here :-)
> >
> >
> > Julien.Pauli
> >
>
>
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

Re: [PHP-DEV][RFC] Callable Types

[Levi Morrison]

> Not much else to say, the syntax reads a bit weird/heavy being all in-line
> with the function signature but at the same time I can't imagine how else it
> would work that would be any better.

As mentioned on Reddit and in the future scope section of union types,
we may want to introduce named type expressions:

type IntReducer = callable(int, int): int;

Which would also allow unions (if passed, of course):

type Iterable = Array | Traversable;

It would also allow for a general type-aliasing mechanism for single
names. This feature has been asked for in the past but I can't
remember the use-cases so this example is not very good:

type Foo = SomeFoo;

Then we just use the names where we would have put the expressions:

function reduce(int $a, int $b, IntReducer $reducer): int {
return $reducer($a, $b);
}

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

Re: [PHP-DEV] PHP 7.1 roadmap

[Ferenc Kovacs]

co-RM can simply mean "one of the two RMs", and emphasize that somebody
would volunteer to take the role but not being comfortable to doing it
alone so I think we are on the same page.

On Fri, Apr 22, 2016 at 2:50 PM, Julien Pauli  wrote:

> On Fri, Apr 22, 2016 at 5:03 AM, Davey Shafik  wrote:
> > I'd interested in co-RMing 7.1 if someone else wants to step up also?
>
> Hi.
>
> The Co-RM is the version-1 RM, so it will be Anatol, RM of 7.0.
> We are looking for a "master" RM here :-)
>
>
> Julien.Pauli
>



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] PHP 7.1 roadmap

[Julien Pauli]

On Fri, Apr 22, 2016 at 5:03 AM, Davey Shafik  wrote:
> I'd interested in co-RMing 7.1 if someone else wants to step up also?

Hi.

The Co-RM is the version-1 RM, so it will be Anatol, RM of 7.0.
We are looking for a "master" RM here :-)


Julien.Pauli

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

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

[Thomas Punt]

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).

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.

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?

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

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-04-22

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-22 06:28:58+03:00
commit: 304e5ae
previous commit:ecf6392
revision date:  2016-04-21 23:49:37+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

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

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.24% -0.59%  0.66%  
  7.09%
:-|   Drupal 7.36 cgi -T1  0.18% -0.11%  0.25%  
  3.47%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11% -0.34%  1.31%  
  3.36%
:-|   bench.php cgi -T100  0.01% -0.77% 25.05%  
 -0.61%
:-|  micro_bench.php cgi -T10  0.02%  0.11%  6.34%  
  1.54%
:-)  mandelbrot.php cgi -T100  0.09%  3.60% 31.33%  
  0.51%
---
* Relative Standard Deviation (Standard Deviation/Average)

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

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

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


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

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


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

Re: [PHP-DEV] [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)
}


<> - doesn't work now, but I'll implement this and extend RFC on 
next week.


Thanks. Dmitry.


From: Dominic Grostate 
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.
<> 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" 
> 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?

<>
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" 
> 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

[Lester Caine]

On 21/04/16 22:13, Dmitry Stogov wrote:
> I would like to present an RFC proposing support for native annotation.

I thought that the debate had been completed on annotation, and since
most of the work can be done in a stand alone extension, the various
parties were going to take that route and develop working options which
could then be compared to decide if any provide a suitable replacement
for the current docbloc 'process' that most of the IDE's currently
recognise.

There is room for proper documentation of the current standard as some
elements are not followed reliably, but on the whole the system works,
and any of the new extensions need to be addressed via IDE projects
before they can replace that.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Nullable Types

[Quim Calpe]

On Thu, Apr 21, 2016 at 9:52 PM, Fleshgrinder  wrote:

> On 4/21/2016 1:00 PM, Lin Yo-An wrote:
> > I think this is not to make PHP like Java, and it totally makes sense -
> > Nullable should be a type of a type instead of a state. In Haskell it's
> > named Maybe or Option, and It's better than NullPointerException.
> >
> > Here is a discussion from Haskell community:
> > https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html
> >
>
> Why is it /better/?
>
> final class None {}
>
> final class Some {
>
> public $value;
>
> public function __construct($value) {
> $this->value = $value;
> }
>
> }
>
> final class Maybe {
>
> private static $none;
>
> private $value;
>
> private function __construct($value) {
> $this->value = $value;
> }
>
> public static function NOTHING() {
> if (self::$nothing === null) {
> self::$nothing = new Nothing();
> }
> return new static(self::$nothing);
> }
>
> public static function SOME($value) {
> return new static(new Some($value));
> }
>
> public function hasSome(): bool {
> return $this->value !== static::$none;
> }
>
> public function isNone(): bool {
> return $this->value === static::$none;
> }
>
> public function unwrap() {
> if ($this->value === static::$none) {
> trigger_error('NullPointerException', E_USER_ERROR);
> }
> return $this->value->value;
> }
>
> }
>
> // 
>
> function f1(): Option {}
>
> $x = f1();
> if ($x->hasSome()) {
> echo $x->unwrap(); // 42
> }
>
> $x = f1();
> if ($x->isNone()) {
> echo -1;
> }
>
> echo f1()->unwrap(); // error: NullPointerException :P
>
> // 
>
> function f2(): ?int {}
>
> $y = f2();
> if (isset($y)) {
> echo $y; // 42
> }
>
> $y = f2();
> if ($y === null) {
> echo -1;
> }
>
> echo f2(); // null
>
> You can easily build your own Option or Maybe and add the additional
> bookkeeping to your runtime but it will not make your program more
> secure or anything. It just adds more method calls and makes it more
> verbose.
>
> You can already use static code analyzers to detect if null is being
> ignored in your code, however, right now they mainly have to rely on
> PhpDoc that is often not properly documented. Adding an explicit syntax
> to PHP for documentation would make PhpDoc obsolete and allow static
> code analyzers to perform their job better and PHP to error out during
> runtime if something else is being returned.
>
> Honestly, null is not our problem. Every language has its null, just
> because they wrap it or rename it does not make null suddenly vanish
> from the universe. :P
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
IMHO, the point of Optional types is the intention, if you get an
Option from a method, you have to deal with a None branch. Of course
you can just unwrap and go on, but it's a developer decision to do that,
not an oversight as using a Foo|null (or ?Foo) as an object directly.

Re: [PHP-DEV][RFC] Callable Types

[Jordi Boggiano]

On 22/04/2016 05:12, Marcio Almada wrote:

Hello everyone,

We just completed the draft for the "Callable Types" RFC. This RFC has been
recently mentioned during other type related threads on this mailing list,
so it feels to be the right time to put the proposal in context:

The proposal is at https://wiki.php.net/rfc/callable-types

The W.I.P patch is available for testing through http://3v4l.org under the
RFC tab.

We count with your detailed feedback and insights. Let's have a nice,
respectful and
constructive conversation about the RFC and work on possible improvements!


Very cool to see work on this. The lack of clear signature definition is 
definitely one of the main hurdles to using "callable" in interfaces for 
plugin systems and such where third parties have to integrate.


Not much else to say, the syntax reads a bit weird/heavy being all 
in-line with the function signature but at the same time I can't imagine 
how else it would work that would be any better.


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

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

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

[Jordi Boggiano]

On 22/04/2016 08:17, Dmitry Stogov wrote:



On 04/22/2016 05:15 AM, Sara Golemon wrote:

On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov  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.

<>

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:

<>

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.


I can't speak for the implementation details, but I see a few benefits 
of having real AST vs a string.. You get syntax highlighting in editors, 
and most importantly compile time syntax errors if you messed up.


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

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

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

[Dominic Grostate]

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.
<> 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"  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?

<>
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"  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  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.

<>

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:

<>

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:

<>

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 > 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?

<>
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"  >> wrote:

Hi,


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

The naming, syntax and behavior are mostly