Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.218.47 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEPJdukON9tn1ELR2Neha=6pSPcbP_6xw-sk6_hgtXiktrqu=w@mail.gmail.com>
References: <BY2PR0201MB17842998E88EF93DEEA9ABACBF710@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CAEPJdumSdAQvf6gx57QFROOQY_fwfq9R2-d4M4giZPUqLnu7WQ@mail.gmail.com>
	<CADyq6sLABxW4D0=7kwHe5wd6tbGX3yRFzaSAv2GJe2A8uJXAhg@mail.gmail.com>
	<CADqTB_jDgHxo80C9A7NuQ6gECBOzC4nTijPyofTVKmLopwaQdw@mail.gmail.com>
	<CAEPJdukON9tn1ELR2Neha=6pSPcbP_6xw-sk6_hgtXiktrqu=w@mail.gmail.com>
Date: Thu, 12 May 2016 22:51:39 +0200
Message-ID: <CADqTB_iyK58eExZbti0i+v4dmUOa8ybpnJvKHn=HHJjrM=aAaw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Marco Pivetta <ocramius@gmail.com>, Dmitry Stogov <dmitry@zend.com>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
From: rasmus@mindplay.dk (Rasmus Schultz)

> What happens if you say <<$x>> and then call $reflection->getAttributes() in your eample? what is $x?
>
> That is the problem with immediately evaluating everything non "constant". There is no context.

There's is no context. Annotations should be context-free - that's by design.

There's also no $this, and no self:: or static:: either, because the
annotations are supposed to be context-free. They're meta-data, not
functions - you already have functions, interfaces, abstract methods
etc. for that.

Suppose you don't have an instance of a class yet, and you reflect and
try to get the value of something that requires context - it doesn't
exist yet. Then what? Obtaining the meta-data before you have an
instance is a common use-case, for example when generating schema from
table/column meta-data attached to entities, you don't have an
instance yet - you're inspecting the class, methods and properties,
not an object.

If you insist on putting something in annotations that requires
context, what you should put in there, is an anonymous function - e.g.
a function that expects the consumer to provide the context, such that
you're not dependent on some implied context, instead you're asking
for a specific context. Dependency injection - good stuff. There's an
example of that in my comment below the gist.

Though personally I would never, ever put functionality in an
annotation - it's a huge misunderstanding, in my opinion. If what you
wanted was executable functionality that requires a context, what you
really want is an interface that you can implement. Context requires a
contract.

Just my opinion, of course, and there's nothing stopping you from
using functions if that's your fancy. And it's much safer and
friendlier to readers, and static analysis tools, not to expect a
run-time context to always be established by the consumer.

Either way, the majority use-case is attaching meta-data to
classes/properties/methods - wanting to attach code and evaluate it at
run-time is a marginal use-case. Designing the whole thing for that
first, and sacrificing all the flexibility of the language itself by
inventing an entirely new concept, which is entirely dependent on
run-time interpretation, in my opinion, is just completely backwards,
when you can do something much, much simpler with far more freedom and
options and design-time safety.


On Thu, May 12, 2016 at 9:27 PM, Benjamin Eberlei <kontakt@beberlei.de> wrote:
>
>
> On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
>>
>> My problem with this PSR is you've created something that strongly
>> resembles function or constructor calls, but in reality is just
>> key/value pairs.
>
>
> Its actually function calls, not constructors calls :-)
>>
>>
>> That's confusing in itself, but also puts an unnecessary burden on
>> consumers who have to figure out how to map this apparently
>> "something" to "something real" - since it really isn't anything other
>> than pretty syntax for arrays associated with source-code elements.
>>
>> Did anybody look at my notes here?
>>
>> https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46
>>
>> I think this is much simpler and far more flexible - it lets you do
>> what you're proposing with attributes (by annotating with simple
>> arrays) and also lets you create annotation classes.
>>
>> Would anyone care to comment?
>
>
> What happens if you say <<$x>> and then call $reflection->getAttributes() in
> your eample? what is $x?
>
> That is the problem with immediately evaluating everything non "constant".
> There is no context.
>>
>>
>>
>> On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta <ocramius@gmail.com> wrote:
>> > On 12 May 2016 at 16:29, Benjamin Eberlei <kontakt@beberlei.de> wrote:
>> >
>> >> On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmitry@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.
>> >> >
>> >> >
>> >> > Thanks. Dmitry.
>> >> >
>> >>
>> >> I voted -1
>> >>
>> >> Reasons: from a Doctrine Annotations maintainer perspective, either
>> >> getting
>> >> a list (without keys) of strings back or ast\nodes are not enough or
>> >> way
>> >> too advanced for our use-case. The middle ground is missing where a
>> >> <php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
>> >> nested array, that means getAttributes() does should not only return
>> >> "string" or ast\node as result for each attribute, to there should be a
>> >> way
>> >> to get arrays back.
>> >>
>> >> Example:
>> >>
>> >> https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25
>> >>
>> >> greetings
>> >> Benjamin
>> >>
>> >
>> > Urgh, that is indeed quirky, and makes it unusable.
>> >
>> > Is that an implementation or a spec issue? I know PHP 5.6+ allows array
>> > constants, but I am not aware of whether that is in the specification.
>> >
>> > Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for
>> > a
>> > version that either explicitly contains any constant expression or just
>> > supports arrays as constants.
>> >
>> > I'll also need to compile the branch and try it out myself before voting
>> > further: my bad for being hasty.
>> >
>> > Marco Pivetta
>> >
>> > http://twitter.com/Ocramius
>> >
>> > http://ocramius.github.com/
>
>