On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, Feb 11, 2015 at 9:50 PM, Marcio Almada <marcio.w...@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
