Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 21 Jul 2005 12:00:06 +0200
Reply-To: Marcus Boerger <mail@marcus-boerger.de>
Message-ID: <14710167408.20050721120006@marcus-boerger.de>
To: Jessie Hernandez <jrhernandez05@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <E3.87.61486.A899ED24@pb1.pair.com>
References: <52.31.61486.E8DCDD24@pb1.pair.com>
	<681697173.20050720083643@marcus-boerger.de> <E3.87.61486.A899ED24@pb1.pair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Namespace Patch, Alpha 3
From: mail@marcus-boerger.de (Marcus Boerger)

Hello Jessie,

Wednesday, July 20, 2005, 8:35:26 PM, you wrote:

> "Marcus Boerger" <mail@marcus-boerger.de> wrote in message
> news:681697173.20050720083643@marcus-boerger.de...
>> Please don't add new ini settings here, living with include_path should be
>> enough, wouldn't it?
>>

> Do we want the import behavior to apply to the existing include path? To me,
> it seems nice to have the include_path and class_path separate. The
> class_path will only be used for classes, and include_path for everything
> else (header/footer code, etc.). Of course, this is just my opinion. What
> does everyone else think?


>> Why can't __autoload decide itself? I mean either it knows it received a
>> namespace class since the string contains a ':' or the function writer
>> has to find out himself.
>>

> Well, when a full namespace import is done, the string will not contain a
> ':'. __autoload would only receive a class name, and there is no easy way
> for __autoload to know which namespace contains that class. That's why a
> separate mechanism is needed from __autoload, that will look into the
> class_path directories (appending the directories for the namespace name)
> for the class file, and if/when found, include that. This is one other
> reason why a separate class_path variable would be useful: the include_path
> might have several directories, and all these would need to be searched,
> even though these directories might not have classes at all. In contrast,
> the directories in class_path are specifically for class files, so the
> searches are faster.


might, might, might only assumptions with the big drawback of adding another
ini setting. My assumption is that i only need one or two include/class
patchs and that they are of course the same since i want to keep my
application files together - for working maintanance for one reason.
Also if __autoload cannot easily get the requested namespace name than a
compilcated solution has to be worked out since otherwise you end up in
nightmare of naming conflicts - how should you know in a situation where
a classname exists in multiple namespaces from which directory to load?
By order of directory? In the end nothing here would really work around the
problem thus we need the full name.

Best regards,
 Marcus                            mailto:mail@marcus-boerger.de