Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92669 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51488 invoked from network); 23 Apr 2016 23:48:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Apr 2016 23:48:40 -0000 X-Host-Fingerprint: 92.170.143.247 LFbn-1-4403-247.w92-170.abo.wanadoo.fr Received: from [92.170.143.247] ([92.170.143.247:19477] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/86-07837-4D90C175 for ; Sat, 23 Apr 2016 19:48:38 -0400 To: internals@lists.php.net Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes References: <20160423230908.BD6F21A800F6@dd1730.kasserver.com> Date: Sun, 24 Apr 2016 01:48:23 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Message-ID: User-Agent: Opera Mail/1.0 (Win32) X-Posted-By: 92.170.143.247 Subject: Re: [PHP-DEV] [RFC] PHP Attributes From: bensor987@neuf.fr ("Benoit Schildknecht") 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" = a = =C3=A9crit: > 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 maintaine= rs. > 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 annotatio= ns >> would be much clearer to any audience. Simply because the name is ver= y >> well known. >> >> I do not see the need for multi-annotation nor multi-value support. I= t >> just creates multiple ways to achieve the exact same thing for no goo= d >> 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 =3D "@" NAME [ " " VALUE ] >> NAME =3D STRING >> VALUE =3D QUOTED-STRING / PHP-CONSTANT / EXPRESSION >> QUOTED-STRING =3D ( "'" / DQUOTE ) STRING ( "'" / DQUOTE ) >> EXPRESSION =3D PHP-CODE ";" >> >> A semicolon would only be required if it is not a single quoted strin= g >> (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. >> >> > >> $name =3D "Richard Fussenegger"; >> $email =3D "php@fleshgrinder.com"; >> >> @author "{$name} <{$email}>" >> class A {} >> >> <")>> >> class B {} >> >> ?> >> >> Requiring PHP code to be terminated with a semicolon should also ensu= re >> that people do not start to write fully-fledged programs in annotatio= ns. >> 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 =3D "(" 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 a= nd >> its file-level doc block: >> >> > @author 'Richard Fussenegger ' >> @copyright '2016 Richard Fussenegger' >> @license 'MIT' >> >> declare(strict_types=3D1); >> >> namespace Fleshgrinder\PhpInternals; >> >> @description 'True annotation support could be a very good thing.' >> @invariant $this->balance >=3D self::MIN_BALANCE; >> class Account { >> >> private const int MIN_BALANCE =3D 0; >> >> private int $balance; >> >> private Person $owner; >> >> @require $sum >=3D 0; >> @ensure $this->balance =3D=3D=3D (old::$balance + $sum); >> public function deposit(int $sum): void { >> $this->balance +=3D $sum; >> } >> >> @require $sum >=3D 0; >> @require $sum <=3D $this->balance - self::MIN_BALANCE; >> @ensure $this->balance =3D=3D=3D (old::$balance - $sum); >> public function withdraw(int $sum): void { >> $this->balance -=3D $sum; >> } >> >> @deprecated 'for various reasons' >> public function setOwner(Person $wner): void { >> $this->owner =3D $owner; >> } >> >> } >> >> @inheritDoc >> class OverdraftAccount extends Account { >> >> private const int MIN_BALANCE =3D -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 fo= r >> method names) since this is what PhpDoc used to use for many years no= w. >> >> We also need to define how people can avoid to collide with internal >> annotations. The typical double-underscore prefix approach that we ha= ve >> 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. >> >> > >> use Doctrine\ORM; >> >> @ORM::entity >> @ORM::table [ >> 'name' =3D> 'user', >> 'unique_constraints' =3D> [ >> 'name' =3D> 'user_unique', >> 'columns' =3D> [ 'username' ], >> ], >> 'indexes' =3D> [ >> 'name' =3D> 'user_idx', >> 'clumns' =3D> [ 'email' ], >> ], >> 'schema' =3D> 'schema_name', >> ]; >> class User {} >> >> ?> >> >> -- >> Richard "Fleshgrinder" Fussenegger >> >> > -- = Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/