Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93380
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <b3f54e07-a19c-83d6-6ad5-e8e4ee56e9d9@gmail.com>
References: <CADqTB_i5WL+rzCuFHkRmXsPj16WDc4eWmpAoFmyeuYXvuOP_NQ@mail.gmail.com>
 <CAEPJdunJ-67CqJq2hzvmnEmuOFQRGpxv8iycq3CnocXR4r20vw@mail.gmail.com>
 <CADqTB_iUDGHXUR5cYUDuzL4XrqJk-Jf0oce_uj6ZUtEYr7fTYw@mail.gmail.com>
 <CAEPJdunVsJWkOez3ERdpsKjFx8oxPmWVropZ5n9VKTfKdokpXg@mail.gmail.com>
 <CADqTB_jzRPG2CNXniyyo2XA36GGy_s29i5SGPfYe4c8gcpnK6g@mail.gmail.com>
 <61e6a083-91c2-799f-9757-02f56fe184e9@gmail.com> <CADqTB_jB-bXU5FjJoEqx-qTCiX6NSoo9YtxxHiX1X40FqmJ9Pg@mail.gmail.com>
 <ec6a9d04-83d0-1b70-4418-281e4b3f5a54@fleshgrinder.com> <CADqTB_jNcQ24=KC68vrpvXAEmeTJH9Xk4kB9Yr4Pi+3vRWsJiw@mail.gmail.com>
 <CADqTB_jM4-3JZt_t2yQtroDfS7ZSSLp6FNmHWVa+kqh3znsNBQ@mail.gmail.com> <b3f54e07-a19c-83d6-6ad5-e8e4ee56e9d9@gmail.com>
Date: Tue, 17 May 2016 12:21:52 -0400
Message-ID: <CAFp73Xsv=gq+yR2qYmXhLiPVk8i_eYaazqr6aRkW7eQD35wTcA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140b648b00bc805330c244e
Subject: Re: [PHP-DEV] [RFC] Simple Annotations
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a1140b648b00bc805330c244e
Content-Type: text/plain; charset=UTF-8

@Rasmus: This approach is too broad, allowing situations like Marco pointed
out. I'd have to vote -1 on it too if you move forward, specially if you
consider things like << "How do I grab this?" >> and other weirdness.


@Rowan: Annotations should be immutable by nature. Still, I would love if
you can detail (in the context of your example) what should be the output
in the following examples:

<<ValidateRange($percentage, 0, 100)>>
function foo(int $percentage) {
    $reflection = new \ReflectionFunction(__FUNCTION__);

    var_dump($reflection->getAnnotations()); // #2
}


$reflection = new \ReflectionFunction("foo");

var_dump($reflection->getAnnotations()); // #1

foo(10);

When executing the code, what should I expect from #1 and #2? I can foresee
that #1 should crash (?) or should it return an ast\node or what?
It all sounds reasonable on #2 what everyone is heavily forcing/suggesting
because of DbC, but it *only* makes sense in the context of a function call
(or a bound object in case of OO members). In any other case its outcome is
unpredictable.




There're 2 potential approaches I can foresee with future for Annotations:

1- This one I see as a simple approach. Take the idea of Dmitry and extend
to support scalars and arrays (only, no objects, no AST\Nodes). Example: <<
Entity(["name" => "User"]) >>
Strings could be easily converted into AST\Nodes internally and DbC would
be possible. Context is inferred at libraries' desire.
Solution here would not have a 1-1 dependency with classes, simplifying the
implementation for meta parameters such as "override", "inherit",
"memoize", "jit", etc.

2- Take an OO approach and correlate 1-1 class. But before that I'd tackle
object initialization first. We'd require to make this to work:

new Foo() {
    "property" => "value"
}

After that, we could get back to Annotations and support a subset of PHP
grammar, similar to this:

<< Foo { "property" => "value" } >>


Why I suggest this approach, some may ask? Simple young padawans... We're
already seeing people discuss about final/read-only properties, where they
could only be set at constructor time. We could easily expose this
possibility through scopes. The {} block would be post constructor, but
still in the initialization context, allowing sets to happen for read-only
properties. It's a smart solution against adding a long list of constructor
arguments (and handling default values for each one) and also a nice
alternative to "named parameters".
However, this approach would still require a 1-1 dependency with classes,
which would make "override", "inherit", "jit" a PITA, and likely empower a
more robust annotation solution (like defining which class can be an
annotation and what cannot, or specify annotation target, like class,
method, property, etc).


PS: I hate to write long emails... =(

Cheers,

On Tue, May 17, 2016 at 11:28 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 17/05/2016 15:22, Rasmus Schultz wrote:
>
>> The other issue is the dependency (context) injection example - no one
>> seems to be able to cite an actual use-case, and if that's the case, I
>> should probably just remove it from the RFC entirely?
>>
>> @Larry can you think of a case example in the myriad annotations
>> you've seen in Drupal code? :-)
>>
>> Anyone else using Doctrine Annotations actually seen anyone making use
>> of a closure in an annotation?
>>
>
> Possibly nobody's responded to your call for an example because they're
> not sure what it is you're asking for an example of. I don't really
> understand what closures have to do with annotations, or how that relates
> to capturing context.
>
> An example from the other thread of a context-bound annotation would be
> implementing validation like this:
>
> <<ValidateRange($percentage, 0, 100)>>
> function foo(int $percentage)
>
>
> This would appear to be unsupported as such by your proposal, so you would
> instead just have to use strings to represent how it needed to be accessed:
>
> <<new ValidateRangeAnnotation('$percentage', 0, 100)>>
>
> and then have extra machinery in the reflection logic to extract the
> parameters and pass them to the object, e.g.
> $annotation->validate($reflected_parameters)
>
>
> This might be the more sensible approach to such an annotation anyway, but
> without any access to variables, I don't really understand the value of
> evaluating an expression for the annotation, just to get a constant value
> that is cached by the Reflection infrastructure.
>
> If the expression would have to be made up entirely of constants anyway,
> might the same "constant expressions" used in class const definitions be a
> better fit than "any valid PHP expression" - plus a specific exception for
> creating objects out of those constant expressions.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

--001a1140b648b00bc805330c244e--