Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32889
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain horde.org designates 66.92.78.250 as permitted sender)
Message-ID: <20071020184554.69044keujpgfelus@technest.org>
Date: Sat, 20 Oct 2007 18:45:54 -0400
To: Stanislav Malyshev <stas@zend.com>
Cc: internals@lists.php.net
References: <20071019224202.20245u5zry52h5c8@technest.org>
	<471A6B32.3080401@zend.com> <20071020172658.1680416b83wxgv6s@technest.org>
	<471A7C88.6090904@zend.com>
In-Reply-To: <471A7C88.6090904@zend.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs)
Subject: Re: [PHP-DEV] Order of class resolution with namespaces
	and	autoload
From: chuck@horde.org (Chuck Hagenbuch)

Quoting Stanislav Malyshev <stas@zend.com>:

> Not entirely correct - namespaces needed to reconcile _multiple_ =20
> libraries, while in case of Exception you need to stay away only =20
> from _one_ set of classes - namely, internal ones. While indeed even =20
> that could be inconvenient, the problem is that it is not possible =20
> to avoid ambiguity in all cases successfully, so we had to choose =20
> how we solve ambiguous cases. We decided to solve it in a way that =20
> gives most old code most chance to work, while knowing that some =20
> people would find some code less convenient with any code. Out =20
> solution allows to explicitly specify your intent in one of these =20
> ways:
> 1. Defining the class
> 2. Importing the name

I agree with this approach, I just disagree about which set of names =20
we should require people to import.

>> say that we are talking about code _inside_ of a namespace. It =20
>> would not add much conversion burden to say that if you want to use =20
>> global classes in a file you are adding a namespace to, then just =20
>> add imports for those classes. If PHP provided a PHP:: namespace =20
>> with all global classes in it
>
> I think it would. It is much easier to keep track on your own =20
> classes than on system classes create by somebody else.

I agree and I think this is an excellent reason that external classes =20
should be imported - that way they are easier to keep track of.

Also, below you say:

> If you are OK with writing imports, then it shouldn't matter too =20
> much which imports you write.

I think that goes both ways. I am okay with importing classes outside =20
of my namespace. It doesn't make sense to me to have to import names =20
inside my own namespace. And the fact that changes to what classes PHP =20
provides can change the order of class resolution seems like =20
unnecessary fragility to me.

I really think people should think about the way their code is =20
organized when they put it in a namespace. And I really don't think =20
it's a bad thing if you need to list your external dependencies using =20
import.

> And with exception of Exception (no pun intended :) I think there =20
> would be not many classes that would have names coinciding with =20
> internal class names.

Remember Date? (now DateTime)? This is mostly true right now because =20
there was no concept of namespacing and only very well organized class =20
libraries prefixed their classes. When people start moving their code =20
into namespaces and then taking advantage of that to remove the =20
prefixing, I think this will be more common.

> Also it would cause autoload call on each use of system classes even =20
> if you never had overridden them at all, which can have significant =20
> impact on the performance - exhaustive autoload search can be very =20
> expensive.

I am not understanding why the extra autoload for system classes is =20
necessary (I do understand why my initial re-ordering of include rules =20
would cause two autoload calls and I agree that that is an awful idea =20
now).

- inside a namespace (Foo::), I try to create a new Exception
- if no Foo::Exception class exists, we try to autoload =20
"Foo::Exception". There is no need to autoload just "Exception".

If what I meant was to create an ::Exception, then I just do import =20
Exception; inside my namespace and the class exists - no autoload is =20
necessary.

Am I missing something?

Sincerely,
-chuck