Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82570
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
Sender: stelian.mocanita@gmail.com
In-Reply-To: <CAOsHV+siAhpJjidgDpBKQJZp67m-YMW-OhHqM42NaOad=eDbUQ@mail.gmail.com>
References: <CAOsHV+t=peeRbvXtDoPL2EnvWsQVHNtNYJ5h_e9VQLeLq-srDA@mail.gmail.com>
	<54DC788E.7000000@hoa-project.net>
	<CAOsHV+tcaUZe+siZA7J=Ym2JGyUS7m+z3Q2M6Aav4R=4FssM9w@mail.gmail.com>
	<54DCADFA.6070908@hoa-project.net>
	<CAOsHV+tL4YDr7aiQO2e7COC0rnPvffvOoU4c5n6XkuaWL2QZ5g@mail.gmail.com>
	<CAG1chopp4WAi5jVbmEAL2EUV8_z5quAB+h1V0ATw4Xxaf_fWHw@mail.gmail.com>
	<CAMc0WS54Fym9eSWDcjJdRfcVzPs9mvyvct7BOiuDgSvVbERnNw@mail.gmail.com>
	<CAOsHV+siAhpJjidgDpBKQJZp67m-YMW-OhHqM42NaOad=eDbUQ@mail.gmail.com>
Date: Fri, 13 Feb 2015 00:55:33 +0100
Message-ID: <CAMc0WS4-NdOmXd5-eeP0NCou4nJq2P2RP9cxp2inA+LpdRhiRg@mail.gmail.com>
To: marcio3w@gmail.com
Cc: reeze <reeze@php.net>, "Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c28c100c72e5050eecdb1c
Subject: Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
From: stelianm@php.net (Stelian Mocanita)

--001a11c28c100c72e5050eecdb1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 13, 2015 at 12:13 AM, Marcio Almada <marcio.web2@gmail.com>
wrote:

> Hi Stellan,
>
> >Hello Marcio,
> > I am inclined to vote no for a couple of reasons:
>
> > 1. This is not a BC-break, I would move the vote to PHP 7.1. The
> reasoning behind this is that the tools in the ecosystem will have a lot
> > of work to get on par with PHP 7 (talking here about stuff like phpmd,
> phpcpd, phploc, newrelic, codeclimate, ides, etc). Since this is
> > not as resonant as the other changes for 7, I would give those people
> some breathing room.
>
> Well, we already have new shiny features for PHP that would require
> updates: for instance the return typehints and possibly the scalar type
> hints. Any code analyzer that would like to stay relevant will need to
> update anyway and perhaps updating these tools is much easier than you
> think :) if you see the patch it's quite minimal and the syntax is easy t=
o
> parse.
>

I am not saying your RFC is the deal breaker, I am saying that the overall
effort grows.


>
> I could compromise to send pull requests and update some of these tools (=
at
> least the open source ones) in time for PHP7 release.
>

Print screen taken, will hold you to your words.


> Other reasons to show you this is not a blocker and tailoring the RFC for
> 7.1 is not the best choice:
>
>  - It will take a while until we see projects with PHP7 as a minimum
> version requirements so if we want the feature it's a good idea to add it
> to a major release.
>
>  - Feature freeze date is possibly March, 2015, possible release date is
> Mid October 201. This means we will have plenty of time to update tooling=
.
> This should not hold any language :)
>
> > 2. I am not a big fan of the syntax, I would much more like a python
> style syntax (yes, I am aware it requires a new reserver keyword)
>
> :) I have a hunch that a python copy syntax will not be proposed because =
of
> the BC break you just mentioned ^
>
> Other languages are using glob braces syntax and it simply works :) Perha=
ps
> you could give it a chance. Many people reply to me saying that they
> preferred python syntax but after a while they started to like the propos=
ed
> syntax too, for PHP.
>

Will compile your PR and give it another try with a bit more open mind and
see how
it goes


>
> This is a very basic feature and I strongly believe that, after all the
> research and discussion, it's a good fit for PHP. Perhaps you might want =
to
> read the discussion again before take your decision. See the previously
> discarded options and the reasons why they were discarded. Maybe you migh=
t
> end up agreeing that the current proposed syntax is a good choice.
>
> Thanks for opening dialog and bringing legit questions before take a
> decision. Good voting!


Thanks for taking the time to read through and explain your angle.


>
> Sincerely,
> M=C3=A1rcio Almada
>

--001a11c28c100c72e5050eecdb1c--