Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98233
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAESVnVrLtPd6WA9idTe=srrx-xtx0YMgwgD1L5fXkBrUDchjZQ@mail.gmail.com>
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com> <CAESVnVrLtPd6WA9idTe=srrx-xtx0YMgwgD1L5fXkBrUDchjZQ@mail.gmail.com>
Date: Tue, 7 Feb 2017 10:51:12 +0100
Message-ID: <CADqTB_h_fX5n8JQgvYz50MPdaqT98FN5esVimkg8OrWmD30sxQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114f9f7a46a2a00547edb0fb
Subject: Re: [PHP-DEV] Namespaces in Core
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a114f9f7a46a2a00547edb0fb
Content-Type: text/plain; charset=UTF-8

Just my two cents, but moving and aliasing core PHP
classes/interfaces/functions sounds like an absolutely horrible idea.

My biggest question is WHY would you do that?

Writing user-space code today that uses the global namespace would be
considered extremely bad practice - no one should do that.

If you move everything from the root namespace into new namespaces, what
will that accomplish? You'll have an empty root namespace. But for what?

If nobody else is using the root namespace for anything, how is it
problematic for the language itself to do that?

Besides, it'll be a decade before you can actually remove the root
namespace aliases.

I don't see the point of changing this, at all.

It will lead to inconsistent code and a lot of meaningless overhead for
developers - who, ultimately, stand to gain nothing from this change.


On Mon, Feb 6, 2017 at 9:27 PM, Sara Golemon <pollita@php.net> wrote:

> On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder <php@fleshgrinder.com>
> wrote:
> > First: I like namespaces in Core but here me out!
> >
> > The PHP (case does not matter) would be the proper vendor name to put
> > Core stuff in, as far as I remember it is also reserved for PHP
> > functionality. There were also numerous discussions about providing a
> > cleaned up API there while maintaining backwards compatibility via
> > aliases and so forth in the non-namespaced Core stuff.
> >
> I've been having this same thought lately since looking at the sodium
> RFC.  Here are my thoughts, centered on the goal of having classes
> (and maybe functions?) in a \php\{extname}\ namespace hierarchy.
>
> 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)
>
> "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.
>
> -Sara
>
> P.S. - wrt libsodium, I think THIS issue is enough for me to come down
> on the side of voting non-namespaced to avoid it being an odd-duck.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114f9f7a46a2a00547edb0fb--