Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <54DE7DD8.5060004@ralphschindler.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>
 <CAEPJdumZFhP+GntbOGSekX7HzMpHbWKxTg3uE1y=aPFgOw44eA@mail.gmail.com> <54DE7DD8.5060004@ralphschindler.com>
Date: Fri, 13 Feb 2015 20:36:14 -0300
Message-ID: <CAOsHV+sPxu2w9OV9Tm-QsNqAw9CR80FzC-eX=XnPZueAQSs1Tg@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3a87d2015579050f00b5a4
Subject: Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
From: marcio.web2@gmail.com (Marcio Almada)

--047d7b3a87d2015579050f00b5a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Ralph

The current namespace implementation is there to group code, which is
> already does fairly successfully.
>
> I have to wonder if it is PHPStorm, IDE's and the like that have
> "encouraged" people to only _use_ class names instead of a particular par=
t
> of a namespace (even if it is up to the last fragment of the namespace
> name). That is a behavior I'd like to see curtailed in the PHP community,
> b/c as Benjamin points out above, syntax that uses up to the last NS
> fragment is far more succinct
>

Please, keep in mind we are not covering only the OOP paradigm. Remember
that functional programmers are a big part of the PHP user base and the
proposal has positive impacts on future proposals for function autoloading.
Please, refer to: https://wiki.php.net/rfc/group_use_declarations#rfc_impac=
t


> Question:
>
> If curly braces are used to mimic block syntax, is the semicolon also
> allowed?  i.e:
>
> 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;
>
> Is this something that should be considered?
>
-ralph
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
This syntax was definitely not proposed neither on research or discussion
phase, therefore it's a new bit on the discussion :)

Despite it's aesthetically appealing at a first sight, I have some thoughts
upon it based on the same criteria used to propose the block syntax present
on the RFC:

1. We aimed for maximum readability. The block syntax delimited with
bracket `{` ... `}` pairs is definitely easier to keep track in comparison
with a colon and semicolon `:`...`;`

2. A block delimited by a double colon and a semicolon `:`  `;` is NOT yet
part of any structure from the PHP. Introducing a brand new element on the
syntax, when bracket delimited blocks `{` ... `}` are already a pervasive
structure on the language, seems unnecessary, specially considering the
previous analysis on loss of readability.

3. This idea also implies a distinct syntax for namespace fragments:
"PhpParser\Node\Stmt:" while least effort approach, that offers the least
cognitive effort to the user land, is to simply have namespace fragments
with a trailing "\" as in "PhpParser\Node\Stmt\".

4. The paired brakets `{` ... `}` proposal stays on the comfort zone from
users already used to C-syntax language family. Introducing a colon and
semicolon to delimit a list in PHP would be new bits. I'd prefer to build
such a feature upon conservation of current PHP style.

These are the my thoughts around your suggestion in comparison with the
proposed syntax on the RFC. Perhaps you have something else to add? :)

Sincerely,
M=C3=A1rcio Almada
https://github.com/marcioAlmada

--047d7b3a87d2015579050f00b5a4--