Re: [RFC] PHP Attributes

From: 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.

« previous php.internals (#92698) next »