Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <11f9c899-77b4-da50-f0f7-dc2d16b1829c@gmail.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>
 <11f9c899-77b4-da50-f0f7-dc2d16b1829c@gmail.com>
Date: Sat, 13 Aug 2016 17:19:53 -0400
Message-ID: <CAFp73Xv=J+L6kS7j4ebLD_Rk5_kj2tb7QQacv6u3QnYr7-j5_A@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Julien Pauli <jpauli@php.net>, 
	=?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Content-Type: multipart/alternative; boundary=94eb2c05578e8fb69c0539fa90d2
Subject: Re: [PHP-DEV] Namespaces internal refactoring
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--94eb2c05578e8fb69c0539fa90d2
Content-Type: text/plain; charset=UTF-8

Hi Stas,

I'll answer your message as it directly refers to links with my name.
I understand the reasons of why namespaces were implemented that way, as I
follow this list for quite a long time. I never complained about the
implementation itself as it was publicly introduced originally back in
August 2008, when first PHP 5.3 alpha 1 got released.

Today I see 2 sides in PHP Internals. One that truly believes that PHP
should adopt more concepts of object orientation, such as Annotations,
Generics, Overloading, Class visibility, Collections, Exceptions, etc (the
side I support) and the other side that wants to make the engine more
robust, stable and faster, without entering in a rollercoaster of new
functionality to be introduced that brings instability.

One thing that didn't change is the constant increase of developers writing
and rewriting software using the language. Now these developers are also
improving their skills, and demanding more flexible ways of achieving their
needs. Language evolution should also be in compass with these new needs,
and that's where I think PHP is struggling to keep up, for a variety of
reasons.

Being a constant contributor to open source and many libraries that now
drives most of what people consider as "Modern PHP", I constantly face
problems with the language itself being unable to achieve my needs. When I
say my needs, I mean needs of heavily used libraries, with hundreds or
thousands of other projects depending on them.

I'll highlight the main driver of "private classes" conceptualization, in
an attempt to make this email short (which I already failed). I wrote a DAG
sorter as part of one of Doctrine packages. Many people started to
instantiate (and use this class, even though it was marked as an @internal)
and consume the benefits it provides, until I changed its API working on a
bug fix. If this class was never intended to be used outside of the scope
of this project, how can restrict its usage by outside packages? Feel free
to provide me answers or alternatives, and I'll happily agree with you that
private classes is a bad idea.

Namespace implementation is now the blocker of many new features that could
help solve complex problems that you don't see on a daily basis, but
library developers face daily. For example: allowing to assess
imported/used structs when declaring a class would drastically reduce the
complexity of Doctrine's annotation parser, which required token_get_all
and several logic to check for what you're including. Is there a better
solution for that too? Well, I'd argue Annotations has a market, and people
are just blind if they don't wanna see it. Answering that implementing
Annotations in userland is a bad idea is like telling a corporation
shouldn't create a product because you don't like it. Makes absolutely no
sense.

I do have a lengthy, detailed and complex plan of how namespace refactoring
could be made, what it would enable feature-wise, and how it would benefit
many projects. I'm open to share with you or any other internals developer,
assess impact over PHP source code and even help implementing it. I'm just
unable to do it all by myself due to my poor C knowledge. What I don't want
to see is blind resistance to language evolution and blaming over something
as badly designed without understanding the circumstances that drove to
that implementation decision.

Regards,


On Sat, Aug 13, 2016 at 3:20 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

--94eb2c05578e8fb69c0539fa90d2--