On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd <dan...@basereality.com> wrote:
> On 21 April 2016 at 22:13, Dmitry Stogov <dmi...@zend.com> wrote:
>> Hi,
>>
>>
>> I would like to present an RFC proposing support for native annotation.
>>
>
> Hi Dmitry,
>
> Although everyone will have an opinion about the syntax, I think there
> is one criticism that should be thought about; the chosen syntax isn't
> future expandable to other concerns.
>
> People have talked about "design by contract" RFCs where annotation
> like data is readable by the engine. The current proposed syntax
> _could_ be used to store DBC data, but it would not be clear what
> would be annotation data to read by the application, and what was DBC
> data to be read by the engine.
>
> Changing the proposed syntax to be something like @attr(...) would
> allow it to be expanded in the future by adding a @contract(...)
> construct:
>
> @attr(test($a + $b > 0)) // This is attribute data read by userland code
> @contract(require($a + $b > 0, 'InvalidFooArgsException')) // This is
> DBC data read by the engine.
> function foo($a, $b) {
> ...
> }
>
> Making features be compatible with future features would avoid a lot
> of potential pain down the road.
Genuine question[1]: how is @attr() different than `<<attr()>>`? Also,
isn't `@attr()` 100% valid user-land code today that can precede
function or constant declarations?
[1] I don't like that I have to make that explicit but it is what it is.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
