Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95124
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.51 as permitted sender)
To: internals@lists.php.net, Julien Pauli <jpauli@php.net>,
 =?UTF-8?Q?Micha=c5=82_Brzuchalski?= <michal@brzuchalski.com>
References: <CABdc3WpGQp+ZA6qSQs-ap5VHntH9tzDQOx333eiobsGxYs=DFQ@mail.gmail.com>
 <CAMUwpuQ9ZUdfziCXQAxuS3Drmh2vPSOkpvXf7cOg0xbdNEgD=g@mail.gmail.com>
 <d1abf6e8-4949-6239-2664-a39d956fab14@gmail.com>
 <f9eb5b0a-1031-ed08-08f3-c67be514436c@fleshgrinder.com>
Message-ID: <11f9c899-77b4-da50-f0f7-dc2d16b1829c@gmail.com>
Date: Sat, 13 Aug 2016 12:20:03 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <f9eb5b0a-1031-ed08-08f3-c67be514436c@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Namespaces internal refactoring
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The current approach to namespaces blocks new features like you see it
> in the following PR. The link already points to the two most relevant
> comments that should give you full context:
> 
> https://github.com/php/php-src/pull/947/#issuecomment-224912697

I don't think this - private classes, etc. - is a good idea. It looks
like Javaization of the language and introducing more and more
complexity without any clear benefit, and AFAIK none of the mainstream
scripting languages have such concept. Anyway, this doesn't even have an
RFC, so I don't see why we should refactor everything to accommodate it.

But it is certainly does not fit the concept of namespaces. It needs
completely different packages concept - one that currently does not
exist on PHP. Trying to bolt it on existing concept is not going to do
any good. I think this is what it should start with - developing a good
concept, not trying to go from code modification to design. Design
should come first, then code modification.

> You might know other approaches to solve this. What I want to say is, we
> should not re-discuss everything that was discussed before, we should
> discuss the proposed features and refactor the namespaces IF it is required.

Indeed.
-- 
Stas Malyshev
smalyshev@gmail.com