Re: Possible ways for a "loader" to solve namespace-conflicts

From: Date: Mon, 19 Apr 2004 08:19:47 +0000
Subject: Re: Possible ways for a "loader" to solve namespace-conflicts
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27978@lists.php.net to get a copy of this message
Zitat von Stefan Neufeind <stefan@neufeind.net>:
Hi, following the threads about namespace-conflict it has turned out that in special cases this might really be a big problem. Due to prefixing of categories in PEAR you can in most cases asume that there will be classes with the same name(s) in a user-application. However this might not be the case for other repositories. which will be invited to co-exist and used extensively as soon as the PEAR-installer gets channel-support. So I was thinking about if there is at least any way to clear a possible name-conflict. What if I have a class X from repository A and one from repository B? If you include it using "X.php" you might run into trouble, depending on which one is listed first in the include_path. But this is even more complicated when you want/need to use both classes in the same script, since class-names are no longer unique. Does there exist any loader-implementation for clearing such name- conflicts - e.g. so that the loader can e.g. explicitly rename all classes X and X_... from repository A when loading them to be A_X_... or whatever? I know this is no optiomal (read: performant) way, if you need to parse every file and class before loading (and modify calls to those classes as well). But is there any better solution somebody can think of?
Yes. Leave that to people wanting to offer packages through channels. If they are nice, they prefix all their classes with a custom name. If not, they would have to deal with their "customers" complaining if there is a namespace clash with PEAR packages. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft

« previous php.pear.dev (#27978) next »