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

[Sebastian Bergmann]

Am 29.04.2016 um 11:48 schrieb Nikita Popov:
> Welcome to another edition of "crazy PHP edge-cases you don't want
> to know about".

I love and hate these edge cases at the same time :)

> I'd like to introduce a restriction that forbids performing dynamic calls
> to scope introspection and modification functions.

+1

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

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

[Jesse Schalken]

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.

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

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

[Dan Ackroyd]

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-DEV] Looking (not very far) ahead to PHP 7.1

[Joe Watkins]

Afternoon internals,

We are hoping for alpha 1 to be available on June 9th, this is a little
over 5 weeks away.

Beta 1 (~1 month after alpha 1) on July 7th will be our feature freeze
date - no new RFC's can target 7.1 after this date.

PHP 7.1 has many things targeting it at the moment, some overlapping,
all of them in various states.

So that the dust is allowed to settle during beta phase, we need to
insist that anything that does not have an implementation by the time beta
1 comes be pushed back to 7.2.

If you are working on a core (/Zend) feature right now, especially
draft (unannounced) features, and are targeting 7.1, as a matter of
courtesy (not requirement), I'd like to ask you to move forward,
post-haste. It would be good (although not required) if we could get /Zend
stuff merged before alpha 1 ... I realize this may be a pipe dream. I'm new
at this, and still have dreams ...

TL:DR, dates for diary:

Alpha 1  June 9th
Beta 1 (freeze)July 7th

Cheers
Joe

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

[Rowan Collins]

Larry Garfield wrote on 05/05/2016 15:24:

<> Translator)>>

<>

<>

I could easily see, for instance, Doctrine annotations building the 
first, PHPUnit the second, and Zend the 3rd.  Those would all be 
legal-ish, but semantically very different.  And there's also then no 
guarantee that $foo >> Translator actually means a bit-shift (I don't 
even know what a bitshift in that case would mean)



To add some context to these examples: the first is borrowing the 
overload of ">>" from C++ (meaning "pass to stream") or similar uses in 
Ruby; the second the use of "|" as a pipe in templating languages like 
Smarty and Twig (meaning "pass expression to modifier function") or good 
old Unix shell tradition; and the third is inspired by PostgreSQL and 
imagines the operator overloaded to mean something like "matches the 
XPath-like expression given".


I'm not sure any of those interpretations would actually be useful in 
the realm of annotations, but operator overloading is the first thing 
that sprung to mind when I wondered what a domain-specific language 
would look like if it were constrained only to producing a valid PHP 
AST. Another trick could be to abuse brackets, e.g. 
"something(anything)" will parse as a function call, but needn't be 
interpreted as one.


Regards,
--
Rowan Collins
[IMSoP]



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

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

[Larry Garfield]

On 05/05/2016 02:07 AM, Dmitry Stogov wrote:




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.


This, I think, is the key point of disagreement.

The proposal does not, actually, provide enough functionality to be 
useful. It's a first step, but it doesn't go far enough to actually 
address the problem space.  Because while it may provide rudimentary 
syntax validation (basically, is it a legal PHP string) it doesn't 
provide any semantic validation (it is a meaningful PHP string if 
interpreted the right way), because it doesn't define "right way".


As Rowan noted, there are lots of technically-legal PHP strings that an 
AST would be totally fine with that are still completely different and 
incompatible as far as actually using them.  To enhance his examples a bit:


<> Translator)>>

<>

<>

I could easily see, for instance, Doctrine annotations building the 
first, PHPUnit the second, and Zend the 3rd.  Those would all be 
legal-ish, but semantically very different.  And there's also then no 
guarantee that $foo >> Translator actually means a bit-shift (I don't 
even know what a bitshift in that case would mean), it could mean 
anything that Doctrine decided to mutate it into.  Does the second 
example actually mean to pipe values, or could it also be parsed into 
something else?  Are lower and escape function names, or magic values 
that my add-on parser knows?


At that point, the only value-add over the status quo (hack the 
docblock) is a common lexer.  But since the semantics are not guaranteed 
on top of that, it's really not that useful.


I'm not fully convinced that all the way to Doctrine classes is the 
right alternative.  It may be, it may not be, I'm not sure yet.  But as 
someone who would be using this system in user-space, I am very 
convinced that the current proposal simply doesn't go far enough to be 
useful to me.


--Larry Garfield

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

Re: [PHP-DEV] Re: ext/curl update

[Nikita Popov]

On Thu, Apr 28, 2016 at 11:30 PM, Davey Shafik  wrote:

> I seem to have created some confusion here:
>
> The reason _my_ patch for Server Push isn't merged is tests for it were
> requested and are blocking it. I'm not saying tests for these constants
> should be added.
>

For the record, I'm fine with landing your server push patch based on
review and manual tests only. It is not an ideal situation, but I don't
think we should block this kind of trivial change on the implementation of
full-blown HTTP 2.0 support in the built-in server. The latter is a much
bigger project, I'm sure it's going to be somewhat controversial (pulls in
new dependencies) and I don't see how this can land on the 7.1 timeline
(unless someone is actively working on a patch already?)

Nikita

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-05-05

[lp_benchmark_robot]

Results for project PHP master, build date 2016-05-05 13:12:21+03:00
commit: 5eecd61
previous commit:ee55110
revision date:  2016-05-05 15:18:24+08: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.13% -0.27%  0.40%  
  7.01%
:-|   Drupal 7.36 cgi -T1  0.14% -0.76% -0.49%  
  4.97%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07% -0.19%  0.48%  
  3.23%
:-)   bench.php cgi -T100  0.02%  2.08% 26.56%  
 -0.34%
:-)  micro_bench.php cgi -T10  0.01%  3.16%  4.82%  
  3.03%
:-)  mandelbrot.php cgi -T100  0.01%  1.41% 32.28%  
 -0.77%
---

* 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-05-05/

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] Attributes/Annotations Case Study: Drupal

[Rowan Collins]

Stanislav Malyshev wrote on 05/05/2016 07:48:

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.



I tend to agree - what the proposal basically says is "here's a generic 
parser, invent a domain-specific language using that parser". 
Theoretically, people could implement all sorts of weird "operator 
overloading" behaviour:


<> Translator)>>

<>

<>

Do we really need or want that kind of flexibility, just to avoid 
agreeing a specific structure for metadata?


Regards,
Rowan Collins
[IMSoP]

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

[Lester Caine]

On 05/05/16 08:34, Dmitry Stogov wrote:
>> 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).

That is all I'm asking ... I thought initially the rfc defined more than
it does, but just creating another 'free for all' on how something is
used seems a pointless exercise?

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

[Alexander Lisachenko]

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.

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

[Stanislav Malyshev]

Hi!

> It's also possible to write:
> 
> <   "id" = "system_branding_block",
>   "admin_label" = @Translation("Site branding")
> ]))>>
> 
> 
> 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, 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.

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.

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

-- 
Stas Malyshev
smalys...@gmail.com

-- 
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] [VOTE][RESULTS] 7.1 RMs selection

[Sebastian Bergmann]

Am 03.05.2016 um 23:36 schrieb Anatol Belski:
> Congrats and godspeed, guys!

Hear, hear!

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