Re: merging Controversial changes back into PEAR2 Standards

On Sep 23, 2007, at 3:33 PM, Gregory Beaver wrote:

Travis Swicegood wrote:

On Sep 23, 2007, at 12:22 PM, Gregory Beaver wrote:

What I think is unclear is the meaning of "dependency" as I used it. I'm referring to external classes - classes declared in other files. By this definition, even PEAR2::Package::Exception is an external dependency. The only alternative to proposal #3 (using import) is that we mandate that all classnames must be used in their entirety, i.e.: throw new ::PEAR2::Package::Exception('blah'); and that import must be avoided inside PEAR2 packages. This is an option, I find it rather unattractive, but it is an option.

Aside from aesthetics, do you have any other issue with it? And how do we handle name clashes? Example:

Yes, the main issue I have is that long classnames make my code very difficult to read and to debug in my experience. For instance, from Pyrus's package.xml 2.0 class:

How will the shortened version display errors? As the aliased code, or as the original? If it's the aliased code that would obfuscate the code, no?

                PEAR2_Pyrus_PackageFile_v2Iterator_FileInstallationFilter::setParent($this);

Pulling one line out of context :-) At this point, would you be working with the PEAR2::Pryus::PackageFile::v2Iterator namespace for that code? If so, you're already inside your declared namespace so you shouldn't need to redeclare, no?

<?php import PackageOne

For the reasons you bring up, this is a no-op. You can only import classes, or alias existing namespaces. You could, for instance, do: import PackageOne as o; and then use o::FooBar(). Or, you can do: import PackageOne::FooBar; (which is equivalent to import PackageOne::FooBar as FooBar;) or import PackageOne::FooBar as anotherclass;

Ok - that makes more sense. Random, off-topic note, does anyone get the feeling they should have just done the ability to alias a class/function structures and been done with it? Back on topic, do imports happen in a file scope, or the current scope? Example: <?php // /path/to/PEAR2/Package.php import PEAR2::FooBar // ... etc., etc. ?> <?php // index.php require '/path/to/PEAR2/Package.php'; class FooBar { } ?> Does index.php throw an error now because it includes a file that imports a prefixed class? If that is the case, I would avoid import at all costs inside PEAR2 code simply to avoid possibly undoing the benefits gained from namespaces/packages. Another issue assuming imports are file level, how will phar handle imports? My understanding, though it may be wrong, is that phar pulls all of the files together in one pseudo-file. If that's the case, doesn't import stand a chance of throwing errors when some class is imported in what would have been one unique file if the names clash with another class in the same code? If that's the case, everything will have to be aliased to something unique which will obfuscate its original meaning. Thanks for taking the time to answer. I know it must be frustrating to have to defend a position against arguments that are based on assumptions. Especially one's like mine can be as so wrong sometimes. :-) -T