Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93387
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.68 as permitted sender)
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>
 <CADqTB_jF+5ARpCn1-sAeM_R0iAzagCXpM65aX3NdPws3HLBqbw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Message-ID: <5fa12e6f-476f-b0e5-b4e3-ea3c7dc1925d@gmail.com>
Date: Tue, 17 May 2016 19:37:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_jF+5ARpCn1-sAeM_R0iAzagCXpM65aX3NdPws3HLBqbw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Simple Annotations
From: rowan.collins@gmail.com (Rowan Collins)

On 17/05/2016 18:47, Rasmus Schultz wrote:
>> 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.

Right, in my mind this is less about *context*, and more about *passing 
code into the implementation*. I think we agree that an implementation 
of validation-by-annotation would look something like:

$validators = $reflected_thing->getAnnotations('someFilter');
foreach ( $validators as $validator ) {
$validator->validate($some_instance);
}

This gets its *context* from the code running the validator; the 
implementation of the validate() method would normally just be part of 
the annotation type:

<<new RangeValidator(1, 100)>>
var $foo;


The closure example you gave would be a way of providing on-the-fly 
dynamic *behaviour* as the argument to an annotation. This wouldn't 
really make sense for validation (a custom validator would still 
probably be defined once and used for several fields, but theoretically 
you could have:

<<new CustomValidator(function($value){ return is_prime($value); })>>

It's not the context that's magic here, it's the ability to specify code 
as part of the annotation *value*, rather than the annotation *definition*.


A more obvious example therefore is using annotations to implement DbC:

<<new Precondition(function($values) { ... })>>

Although as I admitted to Guilherme, that requires some magic to run it 
at the right time anyway...


>> 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
> ) { ... }

Sure, but it's easy to come up with a variant that requires access to 
more than one parameter, say:

<< ValidateLessThan($min, $max) >>
function foo($min, $max)

Which without any context or AST would need to be either:

<< ValidateLessThan('$min', '$max') >>
function foo($min, $max)

...which rather defeats the point of having code rather than just a string.

Or:

<< ValidateCustom(function($min, $max) { return $min < $max } >>
function foo($min, $max)

...which feels rather clunky.


>> 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?

How would you "nest" annotations in your scheme anyway? As far as I can 
see, they would be either multi-level arrays (a valid constant 
expression) or nested constructor calls. So there's still exactly one 
exception made, the "new Foo(args)" construct.


> 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.

That's a fair point. The flipside is that the more things you allow the 
user to do, the more edge cases you have to deal with when evaluating 
the expressions in your special "zero context".


> 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".

I am not suggesting removing the ability to avoid people doing evil; I'm 
suggesting that the feature you call "simple annotations" could be a lot 
simpler.

What is the value of being able to write this:

function foo() { return 'MyAnnotation'; }

<< foo() >>
class A {}

When you could just write this:

<< 'MyAnnotation' >>


> 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...

In my mind, something that lets me evaluate an arbitrary expression in 
some weird null-context, at an unspecified time (because I don't know 
what code will be the first to request that annotation), only to have 
the result stored in some invisible static variable, is *more* complex 
than many of the alternatives.

Regards,
-- 
Rowan Collins
[IMSoP]