Re: [RFC] PHP Attributes

I think it's much less work to parse <<>> as comments in 7.0 instead of having every framework releasing and supporting two packages. In the past, frameworks released new major versions to use new PHP features, but this came with a lot of incompatibilities and many companies skipped the migration hell and stayed with old and unsupported versions. Regards Thomas Benoit Schildknecht wrote on 24.04.2016 01:48: > If I was a popular framework creator, this wouldn't stop me. I would > release two packages : one for 7.0, another one for 7.1. And the 7.0 one > would be the 7.1 one that has been processed through a script to remove > any <<>> syntax, or to transform it (if pre/post attributes instructions > were to be implemented in the core). > > Regards, > Ben. > > Le Sun, 24 Apr 2016 01:09:08 +0200, "Thomas Bley" <mails@thomasbley.de> a > écrit: > >> The <<>> syntax comes with the problem that previous versions cannot >> ignore it on parsing. >> So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, >> then they write new frameworks for 7.1 which cannot be parsed with 7.0 >> and 5.x and so on. >> For companies staying on Linux distributions with long term support on >> 7.0, this is rather a nightmare for both users and framework maintainers. >> When choosing <<>> or any other non-backward compatible syntax for 7.1, >> there should be a patch for 7.0 to ignore the new syntax without parse >> errors. >> >> Regards >> Thomas >> >> Fleshgrinder wrote on 23.04.2016 17:29: >> >>> +1 for the basic idea, however, I have various remarks. >>> >>> The RFC text is hard to read and contains many grammatical mistakes. How >>> could one help you here? >>> >>> I think that the Hack name attributes is unintelligible and annotations >>> would be much clearer to any audience. Simply because the name is very >>> well known. >>> >>> I do not see the need for multi-annotation nor multi-value support. It >>> just creates multiple ways to achieve the exact same thing for no good >>> reason. >>> >>> I do not like the <<>> syntax. It requires many key strokes, is hard to >>> read, and looks ugly. Why not simply @ and be done with it. I am not so >>> sure about the bracket requirement, is it somehow required for the >>> parsing? Otherwise I would leave it off. I guess it might be hard to >>> find the end of an annotation but have you considered to use the >>> semicolon for that? Would align nicely with existing PHP syntax. The >>> following would be the ABNF for my proposal: >>> >>> ANNOTATION = "@" NAME [ " " VALUE ] >>> NAME = STRING >>> VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION >>> QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE ) >>> EXPRESSION = PHP-CODE ";" >>> >>> A semicolon would only be required if it is not a single quoted string >>> (see following example) or constant. A question that I see unanswered is >>> how embedding of variables in quoted strings should be dealt with. I see >>> no need for this but people might assume it is supported because PHP >>> supports it everywhere else. >>> >>> <?php >>> >>> $name = "Richard Fussenegger"; >>> $email = "php@fleshgrinder.com"; >>> >>> @author "{$name} <{$email}>" >>> class A {} >>> >>> <<author("{$name} <{$email}>")>> >>> class B {} >>> >>> ?> >>> >>> Requiring PHP code to be terminated with a semicolon should also ensure >>> that people do not start to write fully-fledged programs in annotations. >>> Since that is not what they are intended for. An alternative approach I >>> see here would be to go for the brackets but then again only for PHP >>> code: >>> >>> EXPRESSION = "(" PHP-CODE ")" >>> >>> Then again, it looks similar to a function call and this is imho not >>> good. Unless of course new annotations can be defined as special >>> functions directly in userland, e.g. with an annotation >>> function >>> and/or annotation class. However, this would require >>> more thought. >>> >>> Another question that is unanswered for me is: how to go about adding >>> annotations to a complete file as is currently possible with PhpDoc and >>> its file-level doc block: >>> >>> <?php >>> @author 'Richard Fussenegger <php@fleshgrinder.com>' >>> @copyright '2016 Richard Fussenegger' >>> @license 'MIT' >>> >>> declare(strict_types=1); >>> >>> namespace Fleshgrinder\PhpInternals; >>> >>> @description 'True annotation support could be a very good thing.' >>> @invariant $this->balance >= self::MIN_BALANCE; >>> class Account { >>> >>> private const int MIN_BALANCE = 0; >>> >>> private int $balance; >>> >>> private Person $owner; >>> >>> @require $sum >= 0; >>> @ensure $this->balance === (old::$balance + $sum); >>> public function deposit(int $sum): void { >>> $this->balance += $sum; >>> } >>> >>> @require $sum >= 0; >>> @require $sum <= $this->balance - self::MIN_BALANCE; >>> @ensure $this->balance === (old::$balance - $sum); >>> public function withdraw(int $sum): void { >>> $this->balance -= $sum; >>> } >>> >>> @deprecated 'for various reasons' >>> public function setOwner(Person $wner): void { >>> $this->owner = $owner; >>> } >>> >>> } >>> >>> @inheritDoc >>> class OverdraftAccount extends Account { >>> >>> private const int MIN_BALANCE = -1000; >>> >>> } >>> >>> ?> >>> >>> We also need to make sure to add something regarding coding standards >>> for annotation names. I would propose to go for camelCase (same as for >>> method names) since this is what PhpDoc used to use for many years now. >>> >>> We also need to define how people can avoid to collide with internal >>> annotations. The typical double-underscore prefix approach that we have >>> for magic methods creates a lot of visual clutter and looks weird if >>> spread among all kinds of places. A namespace approach as we have it >>> already for userland code could help here. >>> >>> <?php >>> >>> use Doctrine\ORM; >>> >>> @ORM::entity >>> @ORM::table [ >>> 'name' => 'user', >>> 'unique_constraints' => [ >>> 'name' => 'user_unique', >>> 'columns' => [ 'username' ], >>> ], >>> 'indexes' => [ >>> 'name' => 'user_idx', >>> 'clumns' => [ 'email' ], >>> ], >>> 'schema' => 'schema_name', >>> ]; >>> class User {} >>> >>> ?> >>> >>> -- >>> Richard "Fleshgrinder" Fussenegger >>> >>> >> > > > -- > Utilisant le logiciel de courrier d'Opera : > http://www.opera.com/mail/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >