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