Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82636 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73073 invoked from network); 13 Feb 2015 18:12:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Feb 2015 18:12:16 -0000 Authentication-Results: pb1.pair.com header.from=kontakt@beberlei.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=kontakt@beberlei.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.52 cause and error) X-PHP-List-Original-Sender: kontakt@beberlei.de X-Host-Fingerprint: 74.125.82.52 mail-wg0-f52.google.com Received: from [74.125.82.52] ([74.125.82.52:45239] helo=mail-wg0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 11/D6-40724-F7E3ED45 for ; Fri, 13 Feb 2015 13:12:16 -0500 Received: by mail-wg0-f52.google.com with SMTP id x12so8395284wgg.11 for ; Fri, 13 Feb 2015 10:12:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eK7hp1KXB5QiJA4cZyHn03Md1DP8D+fK26vpJWuRpzA=; b=B9xEIcmlBjpc01heSDpM/8WhPM/tOnL08HGIPO5sSwtj3J87A7apXQQcTWiO0iafNT 6Csy+OzUG6i2l6oLXO61C+Wm7oZwlxSMf1aR1iDdbUfPLMheWJXYMML4NBLK7Ryvy2+5 0qbnSWCRo/ArsFTNuCf9RkM0C9SG+0b5hMb2MIODP2MyujpACM3WJv7mBfUHILAk57D1 oiUVsZVefqJdUUCEX4KakM9KePI17rTiQ4psstSROUVK6ILCbcU2a5pxj1KsKePRN2q9 lioEuNqW0S6Vu7HnGk/mCkWqrAqzmnZUxsr0FbRgsBF3LSmEUYrUwEaiVMX+eoxIZXzG zIrA== X-Gm-Message-State: ALoCoQmq1K4zxGUdcUwlU8roupyh1MDJ2qQ6X0XVu29C5pFQgsVu8IjoamtOKbXqVabDyiz68wvZ MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr20359354wjc.111.1423851133449; Fri, 13 Feb 2015 10:12:13 -0800 (PST) Received: by 10.194.192.202 with HTTP; Fri, 13 Feb 2015 10:12:13 -0800 (PST) X-Originating-IP: [93.129.146.161] In-Reply-To: References: Date: Fri, 13 Feb 2015 19:12:13 +0100 Message-ID: To: Nikita Popov Cc: marcio3w@gmail.com, PHP internals Content-Type: multipart/alternative; boundary=047d7bacb11e05cdb6050efc2d78 Subject: Re: [PHP-DEV][RFC][VOTE] Group Use Declarations From: kontakt@beberlei.de (Benjamin Eberlei) --047d7bacb11e05cdb6050efc2d78 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 13, 2015 at 5:50 PM, Nikita Popov wrote: > On Fri, Feb 13, 2015 at 5:24 PM, Nikita Popov > 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 > --047d7bacb11e05cdb6050efc2d78--