Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94986
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.175 as permitted sender)
To: 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>
Cc: PHP Internals List <internals@lists.php.net>
Message-ID: <d1abf6e8-4949-6239-2664-a39d956fab14@gmail.com>
Date: Wed, 10 Aug 2016 01:47:30 -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: <CAMUwpuQ9ZUdfziCXQAxuS3Drmh2vPSOkpvXf7cOg0xbdNEgD=g@mail.gmail.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!

> It is.
> 
> I agree with your thoughts.
> Back in 2008, namespaces were designed and added to PHP 5.3 as just
> substrings in class names.

That is correct (except that namespaces first appeared in 2007, first
commit f32ffe9b430b718628f868e449c1fcbdc8ec9ef6 if you're interested, of
course were many since then that changed stuff :). However, I do not
think what follows is.

> That is not the right way to do things, but we had not that much time
> to design them otherwise, and we did not want to break the API too
> much by adding new structures.
> So, namespaces were designed as "just" some substrings in class names,
> with all the problems you spot.

Designing namespaces as they are was a deliberate design decision, and
it was not because we "didn't want to break APIs" or because we did not
know better or were afraid of adding another struct, but because it was
decided to choose a simple solution that allows to achieve a lot without
introducing a lot of complexity. I certainly object to the blanket
characterization of it as "not the right way to do things".

I took part in the implementation and though it was almost 9 years ago,
I think I still remember at least something :)

We did consider using something like Java or Python packages, and we
decided it's much too complex and not very suitable for dynamic world of
PHP where classes and class files can be loaded at any time at any order.

I think some people misunderstand this concept and think PHP namespaces
are like half-baked Java packages but without some features because we
were too short-sighted or too hasty to implement those. No, they are not
like Java packages and they are implemented as not being separate
entities but being name prefixes very consciously and deliberately.

Now, 9 years later, we can reopen this question and think maybe our
needs changed and maybe different model would serve us better. This is
certainly possible and there's nothing wrong with that. But I think we
need to approach it with right understanding of why we took certain
decisions and where these decisions come from. It is very wrong to
refactor something without understanding why it was built like that in
the first place, and without understanding the initial design and
requirements. We spent a real lot of time discussing all this stuff, and
it'll be a pity if we spend this time again without using our previous
experience.

I also don't see any need in having "namespace registry", and, in fact,
if you understand conceptual model of PHP namespaces as they are now, it
doesn't make much sense to me.
-- 
Stas Malyshev
smalyshev@gmail.com