[RFC][VOTE] Group Use Declarations

>> Thanks for the RFC! >> We discussed a little bit with the Hoa [1]'s and fruux [2]'s community > and we have a question. >> Why not pretending we have an array of symbols, something like: >> use Foo\Bar\[Baz, Qux]; >> instead of >> use Foo\Bar\{Baz, Qux}; >> This is a list vs. block debate. While I personally would go for `{` and > `}`, here we declare a list, so we guess the array syntax >> would be more tailored. >> Thoughts? > Hi,

> This is an interesting one. During research, the `[` and `]` syntax was > considered for a while but it quickly felt apart for the following reasons: > > 1. Most people considered on PHP the array construct is a very important > building block and therefore we should avoid to multiplex or reuse its > syntax in multiple contexts. This becomes more clear in cases involving > conflict resolutions: > > use Foo\Bar\[Baz *as* Buz, Qux\Quaz *as* Quiz];

> 2. Block syntax seemed more versatile and prone to reuse because we already > have the traits conflict resolution syntax: > > http://php.net/manual/en/language.oop5.traits.php#language.oop5.traits.conflict > > The reasoning for using commas to delimit imported entities and not `;` is > that current use declaration syntax is a comma separated list: > > use function foo\math\sin, foo\math\cos, foo\math\cosh; > > Hence the `{..., ...}` syntax seemed the most tailored to feel similar and > obvious for most of the current PHP userbase, based on all experiments: > > use function foo\math\{ sin, cos, cosh }; > use function Foo\Bar\{ A, B as Baz, C }; > > I hope that the given information is useful to your decision process. Good > voting!

> For Human type experience, {} is harder than () to type, see your > keyboard, can you easier type {} or easier type ()

> I hate {} > > If you like to use {} as the group symbols, i would not like it. > It hurts my fingers.

> I like use Foo\Bar\(Baz, Qux);

> For Human type experience, {} is harder than () to type, see your > keyboard, can you easier type {} or easier type ()

> I hate {}

> If you like to use {} as the group symbols, i would not like it. > It hurts my fingers.

> For Human type experience, {} is harder than () to type, see your > keyboard, can you easier type {} or easier type () > > I hate {} > > If you like to use {} as the group symbols, i would not like it. > > It hurts my fingers. >

> But with Marcio’s proposal, we could instead write this: > > use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};

> > Hey, > > > On 13 Feb 2015, at 16:24, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > > I'm in favor of this RFC. Honestly I don't really understand the

> > it is getting around here. > > > > The ability to import multiple items from one namespace is a > > well-established feature you'll find in many languages employing some

> > of namespacing. I don't think the availability of what I lovingly call

> > vomit" is a good reason to decline a feature - a programming language > > should be able stand on its own and not require IDE assistance for > > reasonable use. > > > > The syntax seems pretty obvious as well - but maybe I just had too much > > exposure to Rust, which makes extensive use of the same syntax. > > My thoughts echo Nikita’s. > > I think this feature would be especially important if PHP gets function

> > This feature is familiar to people who have used other languages, as

> > from somelibrary.math import sin, cos, tan, degrees, radians > > Simple, uncumbersome, readable. > > The equivalent in PHP is this: > > use function SomeLibrary\Math\sin; > use function SomeLibrary\Math\cos; > use function SomeLibrary\Math\tan; > use function SomeLibrary\Math\degrees; > use function SomeLibrary\Math\radius; > > Ouch. Not fun to type, not fun to read, takes up way more space than it

> > But with Marcio’s proposal, we could instead write this: > > use function SomeLibrary\Math\{sin, cos, tan, degrees, radius}; > > Much better, no? I know which one I’d rather read and write. > > It’d be a real shame if this doesn’t pass.

> On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > > I'd like to follow up with another point. I've seen multiple people claim > that code that requires so many "use"s that this proposal becomes relevant > violates the single responsibility principle, because it simply uses too > many different classes. > > I don't think that this statement is correct and would like to provide an > example. The responsibility of the NameResolver class [1] from the > php-parser project is to resolve all names to be fully qualified where > possible (which sounds reasonably narrow to me). However in order to do > this it must consider a large number of different AST nodes, so that the > full import list (if you individually import every class, which is > customary in PHP) would look as follows: > > use PhpParser\NodeVisitorAbstract; > use PhpParser\Error; > use PhpParser\Node; > use PhpParser\Node\Name; > use PhpParser\Node\Name\FullyQualified; > use PhpParser\Node\Stmt\Namespace_; > use PhpParser\Node\Stmt\Use_; > use PhpParser\Node\Stmt\Class_; > use PhpParser\Node\Stmt\Interface_; > use PhpParser\Node\Stmt\Trait_; > use PhpParser\Node\Stmt\Function_; > use PhpParser\Node\Stmt\Const_; > use PhpParser\Node\Stmt\Catch_; > use PhpParser\Node\Stmt\TraitUse; > use PhpParser\Node\Stmt\TraitUseAdaptation\Precedence; > use PhpParser\Node\Expr\StaticCall; > use PhpParser\Node\Expr\StaticPropertyFetch; > use PhpParser\Node\Expr\ClassConstFetch; > use PhpParser\Node\Expr\New_; > use PhpParser\Node\Expr\Instanceof_; > use PhpParser\Node\Expr\FuncCall; > use PhpParser\Node\Expr\ConstFetch; > > Damn, this looks unwieldy. With this proposal it becomes: > > use PhpParser\{NodeVisitorAbstract, Error, Node}; > use PhpParser\Node\{Name, Name\FullyQualified}; > use PhpParser\Node\Stmt\{ > Namespace_, Use_, Class_, Interface_, Trait_, Function_, > Const_, Catch_, TraitUse, TraitUseAdaptation\Precedence}; > use PhpParser\Node\Expr\{ > StaticCall, StaticPropertyFetch, ClassConstFetch, New_, > Instanceof_, FuncCall, ConstFetch}; > > Which in my eyes is a much cleaner. There are simply some things that > require interacting with a lot of different classes - processing a syntax > tree is one of those. >

> On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > >> On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada <marcio.web2@gmail.com> >> wrote: >> >>> Hi internals! >>> >>> Since no new discussion topics appeared, the voting on the Group Use >>> Declarations RFC for PHP7 is now open: >>> >>> RFC: https://wiki.php.net/rfc/group_use_declarations#votes >>> Patch: https://github.com/php/php-src/pull/1005 >>> >>> As requested I've split the vote into two slightly different syntax >>> choices, so be sure to pick the right choice if you are going to vote >>> yes. >>> The voting will close in exactly 14 days counting from now. >>> >> >> I'm in favor of this RFC. Honestly I don't really understand the >> negativity it is getting around here. >> >> The ability to import multiple items from one namespace is a >> well-established feature you'll find in many languages employing some kind >> of namespacing. I don't think the availability of what I lovingly call "IDE >> vomit" is a good reason to decline a feature - a programming language >> should be able stand on its own and not require IDE assistance for >> reasonable use. >> >> The syntax seems pretty obvious as well - but maybe I just had too much >> exposure to Rust, which makes extensive use of the same syntax. >> > > I'd like to follow up with another point. I've seen multiple people claim > that code that requires so many "use"s that this proposal becomes relevant > violates the single responsibility principle, because it simply uses too > many different classes. > > I don't think that this statement is correct and would like to provide an > example. The responsibility of the NameResolver class [1] from the > php-parser project is to resolve all names to be fully qualified where > possible (which sounds reasonably narrow to me). However in order to do > this it must consider a large number of different AST nodes, so that the > full import list (if you individually import every class, which is > customary in PHP) would look as follows: > > use PhpParser\NodeVisitorAbstract; > use PhpParser\Error; > use PhpParser\Node; > use PhpParser\Node\Name; > use PhpParser\Node\Name\FullyQualified; > use PhpParser\Node\Stmt\Namespace_; > use PhpParser\Node\Stmt\Use_; > use PhpParser\Node\Stmt\Class_; > use PhpParser\Node\Stmt\Interface_; > use PhpParser\Node\Stmt\Trait_; > use PhpParser\Node\Stmt\Function_; > use PhpParser\Node\Stmt\Const_; > use PhpParser\Node\Stmt\Catch_; > use PhpParser\Node\Stmt\TraitUse; > use PhpParser\Node\Stmt\TraitUseAdaptation\Precedence; > use PhpParser\Node\Expr\StaticCall; > use PhpParser\Node\Expr\StaticPropertyFetch; > use PhpParser\Node\Expr\ClassConstFetch; > use PhpParser\Node\Expr\New_; > use PhpParser\Node\Expr\Instanceof_; > use PhpParser\Node\Expr\FuncCall; > use PhpParser\Node\Expr\ConstFetch; > > Damn, this looks unwieldy. With this proposal it becomes: > > use PhpParser\{NodeVisitorAbstract, Error, Node}; > use PhpParser\Node\{Name, Name\FullyQualified}; > use PhpParser\Node\Stmt\{ > Namespace_, Use_, Class_, Interface_, Trait_, Function_, > Const_, Catch_, TraitUse, TraitUseAdaptation\Precedence}; > use PhpParser\Node\Expr\{ > StaticCall, StaticPropertyFetch, ClassConstFetch, New_, > Instanceof_, FuncCall, ConstFetch}; > > Which in my eyes is a much cleaner. There are simply some things that > require interacting with a lot of different classes - processing a syntax > tree is one of those. > > Lastly I would also encourage everyone to see beyond the usual > object-oriented mindset. PHP is a multi-paradigm language and object- or > class-oriented code are not the end of the line. While, by convention, PHP > uses a 1-to-1 mapping for classes to files, this is not at all common for > functional and functional-ish code. If you write function-based libraries > you will define many functions in one file, which will again make use of > many other functions (which are preferably imported). As such you can end > up with many imports without any SRP violation. > > Thanks, > Nikita > > [1] > https://github.com/nikic/PHP-Parser/blob/master/lib/PhpParser/NodeVisitor/NameResolver.php >