> I don't really understand what closures have to do with annotations, or how
> that relates to capturing context.
The point is that, rather than trying to capture context, you can just
as well ask for what you need.
I'm going to use a very contrived example, because I really can't
think of any real case that requires context:
class User
{
<< new Validation(function ($value) { return false !==
filter_var($value, FILTER_VALIDATE_EMAIL); }) >>
public $email;
}
Like I said, extremely contrived - in practice, you wouldn't need to
attach functionality in that way.
> An example from the other thread of a context-bound annotation would be
> implementing validation like this
You're not annotating the function - this is just a round-about way of
annotating the argument.
You would do that directly, like this:
function foo(
<< ValidateRange(0, 100) >>
int $percentage
) { ... }
> 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.
Probably not - what happens with what is today "nested annotations"
then? Or will you make an exception for those too?
The problem is, you're just reinventing a subset of the programming
language, and I'm sure you can keep expanding on that indefinitely.
What for? Just use the facilities already defined by the language.
This fear of any feature that lets you do "evil" is incomprehensible
to me. Most features of almost any programming language can be used
for "evil". IMO, the real question is whether a feature accomplishes
what you want. If you insist on something that also prevents things
you don't want, you're bound to end up with something a lot more
complex that fits into the language a lot less naturally...
On Tue, May 17, 2016 at 5:28 PM, 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
