[RFC][VOTE] Group Use Declarations

Thanks for the RFC!
We discussed a little bit with the Hoa [1]'s and fruux [2]'s community
and we have a question.
Why not pretending we have an array of symbols, something like:
use Foo\Bar[Baz, Qux];
instead of
use Foo\Bar{Baz, Qux};
This is a list vs. block debate. While I personally would go for { and
}, here we declare a list, so we guess the array syntax
would be more tailored.
Thoughts?
Hi,
Hi :-),

This is an interesting one. During research, the [ and ] syntax was
considered for a while but it quickly felt apart for the following reasons:

1. Most people considered on PHP the array construct is a very important
   building block and therefore we should avoid to multiplex or reuse its
   syntax in multiple contexts. This becomes more clear in cases involving
   conflict resolutions:

use Foo\Bar[Baz as Buz, Qux\Quaz as Quiz];
+1.

2. Block syntax seemed more versatile and prone to reuse because we already
   have the traits conflict resolution syntax:

http://php.net/manual/en/language.oop5.traits.php#language.oop5.traits.conflict

The reasoning for using commas to delimit imported entities and not ; is
that current use declaration syntax is a comma separated list:

use function foo\math\sin, foo\math\cos, foo\math\cosh;

Hence the {..., ...} syntax seemed the most tailored to feel similar and
obvious for most of the current PHP userbase, based on all experiments:

use function foo\math{ sin, cos, cosh };
use function Foo\Bar{ A, B as Baz, C };

I hope that the given information is useful to your decision process. Good
voting!
Yup sure. We are going to vote yes (behind my nickname).
However, while I agree with all your arguments, we have more syntax and
more semantics, it's kind of confusing :-/. But it's a small one, so +1
for us.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. computer scientist
Hacker
http://mnt.io/

Hi,

2015-02-13 1:33 GMT+01:00 Netroby hufeng1987@gmail.com:

For Human type experience, {} is harder than () to type, see your
keyboard, can you easier type {} or easier type ()

That depends on your keyboard and its configuration and might not be
true for the majority of php users.

I hate {}

If you like to use {} as the group symbols, i would not like it.
It hurts my fingers.

All block definitions in php use the {} syntax as do many other
languages. While the usage of the short array syntax would be
understandable () appears to be (in my personal opinion) out of line.

Thanks for your time

Hi,

I like use Foo\Bar(Baz, Qux);

For Human type experience, {} is harder than () to type, see your
keyboard, can you easier type {} or easier type ()

I hate {}

If you like to use {} as the group symbols, i would not like it.
It hurts my fingers.

Your suggested syntax was considered. But it ended up being discarded
during research phase because use Foo\Bar(Baz, Qux); looks too much like a
full qualified function call. That's not good for PHP. Maybe it's good for
Haskell but certainly not good for PHP.

No one here wants to hurt your little finger. Perhaps you should use a
Chinese keyboard with a better layout for programming? :)

Sincerely,
Márcio Almada
https://github.com/marcioAlmada

Hi,

For Human type experience, {} is harder than () to type, see your
keyboard, can you easier type {} or easier type ()

I hate {}

If you like to use {} as the group symbols, i would not like it.

It hurts my fingers.

If you look at your keyboard, you'll also notice that double quotes
are harder to type than single ones. This is not a valid argument.

Cheers,
Andrey.

But with Marcio’s proposal, we could instead write this:

use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};

Well it used to be simply ...

require SomeLibrary\math.php;

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Hey,

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.

My thoughts echo Nikita’s.

I think this feature would be especially important if PHP gets function
autoloading (which it may yet gain in PHP 7 - a certain someone has been
working on it). Currently, sets of independent functions have to be
implemented as static classes. But with function autoloading, they’d have
to be imported independently, and that would lead to way too many use
statements.

This feature is familiar to people who have used other languages, as
Nikita mentioned. In Python, I might do this:

from somelibrary.math import sin, cos, tan, degrees, radians

Simple, uncumbersome, readable.

The equivalent in PHP is this:

use function SomeLibrary\Math\sin;
use function SomeLibrary\Math\cos;
use function SomeLibrary\Math\tan;
use function SomeLibrary\Math\degrees;
use function SomeLibrary\Math\radius;

Ouch. Not fun to type, not fun to read, takes up way more space than it
should. This is just a modest five functions, too - in many cases you’d be
importing more.

But with Marcio’s proposal, we could instead write this:

use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};

Much better, no? I know which one I’d rather read and write.

It’d be a real shame if this doesn’t pass.

Fully agree here, with every said by Nikita and Andrea.

I feel again a gap between ppl using php, writing a lot of this code and
us. This is worrisome.

Cheers,
Pierre

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

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

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

Hi,

The voting for Group Use Declarations is now closed with 39 "yes" and 19
"no" votes. According to the established 2/3 majority requirement, it
passed.

https://wiki.php.net/rfc/group_use_declarations#votes

If you voted "no": your feedback is still as important as before, specially
in case you think something needs to be improved in the future.

Thanks,
Márcio