Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32887
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <471A7C88.6090904@zend.com>
Date: Sat, 20 Oct 2007 15:09:12 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Chuck Hagenbuch <chuck@horde.org>
CC:  internals@lists.php.net
References: <20071019224202.20245u5zry52h5c8@technest.org>	<471A6B32.3080401@zend.com> <20071020172658.1680416b83wxgv6s@technest.org>
In-Reply-To: <20071020172658.1680416b83wxgv6s@technest.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Order of class resolution with namespaces and	autoload
From: stas@zend.com (Stanislav Malyshev)

> Calling exception classes something other than Exception is kind of like 
> giving up on the namespace - if I have to name my classes, *inside* 

Not entirely correct - namespaces needed to reconcile _multiple_ 
libraries, while in case of Exception you need to stay away only from 
_one_ set of classes - namely, internal ones. While indeed even that 
could be inconvenient, the problem is that it is not possible to avoid 
ambiguity in all cases successfully, so we had to choose how we solve 
ambiguous cases. We decided to solve it in a way that gives most old 
code most chance to work, while knowing that some people would find some 
code less convenient with any code. Out solution allows to explicitly 
specify your intent in one of these ways:
1. Defining the class
2. Importing the name

> say that we are talking about code _inside_ of a namespace. It would not 
> add much conversion burden to say that if you want to use global classes 
> in a file you are adding a namespace to, then just add imports for those 
> classes. If PHP provided a PHP:: namespace with all global classes in it 

I think it would. It is much easier to keep track on your own classes 
than on system classes create by somebody else. And with exception of 
Exception (no pun intended :) I think there would be not many classes 
that would have names coinciding with internal class names.

> (as aliases), then you could just do import PHP and be done with it. 
> People who wanted their namespace to be used instead would just not do 
> that.

If you are OK with writing imports, then it shouldn't matter too much 
which imports you write. Right now you need to write your imports - or 
explicitly specify the class, or load the class. I would like to find 
better solution, but completely masking system classes with overloads 
and allowing only :: to work doesn't seem the best way to me currently. 
Also it would cause autoload call on each use of system classes even if 
you never had overridden them at all, which can have significant impact 
on the performance - exhaustive autoload search can be very expensive.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com