Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.49 as permitted sender)
To: PHP internals <internals@lists.php.net>
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com>
 <CAESVnVrLtPd6WA9idTe=srrx-xtx0YMgwgD1L5fXkBrUDchjZQ@mail.gmail.com>
Cc: Sara Golemon <pollita@php.net>
Message-ID: <a8d24d41-bd3a-0881-3fcb-9366fe974c28@gmail.com>
Date: Mon, 6 Feb 2017 18:01:05 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVrLtPd6WA9idTe=srrx-xtx0YMgwgD1L5fXkBrUDchjZQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Namespaces in Core
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> New classes within 7.2 (e.g. \HashContext) to be moved without concern
> for BC (e.g. \php\Hash\HashContext)
> 
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

Do we really need this? I mean, it's not very likely that there's
another RecursiveIteratorIterator in PHP code, and in user code it'd be
namespaced anyway... It just looks like a lot of moving things around
without any visible (at least visible to me) benefit. And given that no
code would be able to use the long name for like 10 years, and even then
why would anybody use long name if short one works.... In general, I
don't see a point. New exts/features - sure.

> "Aliasing" could be potentially accomplished in a few ways:
> 1. Literally just class_alias().  Put another copy of the
> zend_class_entry into the EG(class_table) under a different name.
> 2. "Auto-use": Compile-time analysis of classname: "Is it in this list
> of BC classes? Implicitly map it."
> 3. ...?
> 
> I like #2 because we can raise compile-time deprecation warnings and
> we don't introduce any runtime overhead for most cases.
> 
> Obviously, no removal of support for non-namespaced names until AT LEAST PHP 8.0
> 
> This two big unanswered questions for me before I'd put this into an RFC are:
> 1. How to achieve BC in the best way
> 2. What to do about functions/constants? Instinct says move 'em just
> like classes.

I don't really want \PHP\Core\Constants\E_NOTICE. This looks like
annoying parts of Java too much. I mean, namespaces are great, I use
them every day, they are super-helpful - but that doesn't mean we should
put everything in deep namespaces - especially things that are already
quite fine without them.

-- 
Stas Malyshev
smalyshev@gmail.com