Re: [RFC] PHP Attributes
| From: | Levi Morrison | Date: | Sun, 24 Apr 2016 16:57:58 +0000 |
| Subject: | Re: [RFC] PHP Attributes | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-92698@lists.php.net to get a copy of this message | ||
On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd <danack@basereality.com> wrote:
> On 21 April 2016 at 22:13, Dmitry Stogov <dmitry@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.