Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82693
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <CAF+90c8GiZr+UOvfBRExvRcnmxE8Reu=WT8itkfGzGL-dkcr1w@mail.gmail.com>
References: <CAOsHV+t=peeRbvXtDoPL2EnvWsQVHNtNYJ5h_e9VQLeLq-srDA@mail.gmail.com>
 <CAF+90c-4ZTpsoEfRjajtwjwVo+SaspxT1zEh0k5icLQj30JjNA@mail.gmail.com> <CAF+90c8GiZr+UOvfBRExvRcnmxE8Reu=WT8itkfGzGL-dkcr1w@mail.gmail.com>
Date: Sat, 14 Feb 2015 14:19:39 -0300
Message-ID: <CAOsHV+uW9n67651RszvJONnd3QwvrfeZeqJy9iPv0akemrYJGw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134573c1a9d31050f0f90d8
Subject: Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
From: marcio.web2@gmail.com (Marcio Almada)

--001a1134573c1a9d31050f0f90d8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-02-13 13:50 GMT-03:00 Nikita Popov <nikita.ppv@gmail.com>:

> 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 ki=
nd
>> 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 relevan=
t
> 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, PH=
P
> 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
>

That's a great use case NikiC, I couldn't give a better one. A link to this
email http://news.php.net/php.internals/82622 was added to the RFC.

Thanks,
M=C3=A1rcio

--001a1134573c1a9d31050f0f90d8--