On Fri, Feb 13, 2015 at 5:50 PM, Nikita Popov <nikita....@gmail.com> wrote:

> On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov <nikita....@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.
>

You could very well argue that this is what relative syntax is for:

use PhpParser\NodeVisitorAbstract;
use PhpParser\Error;
use PhpParser\Node;
use PhpParser\Node\Stmt;
use PhpParser\Node\Expr;

then foo(Expr\New_ $expr)

That is even more readable and cleaner to read.

The same applies to importing many functions. For example in Go you can
only ever import namespaces (packages)
and they are always called with "namespace.Function", for example:
strings.Trim("foo")


>
> 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
>

Reply via email to