Re: merging Controversial changes back into PEAR2 Standards

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: | case 'installcontents' : PEAR2_Pyrus_PackageFile_v2Iterator_FileInstallationFilter::setParent($this); return new PEAR2_Pyrus_PackageFile_v2Iterator_File( new PEAR2_Pyrus_PackageFile_v2Iterator_FileInstallationFilter( new PEAR2_Pyrus_PackageFile_v2Iterator_FileContents( $this->_packageInfo['contents'], 'contents', $this)), RecursiveIteratorIterator::LEAVES_ONLY); case 'packagingcontents' : PEAR2_Pyrus_PackageFile_v2Iterator_PackagingIterator::setParent($this); return new PEAR2_Pyrus_PackageFile_v2Iterator_PackagingIterator( $this->_filelist); | This could easily be much more readable and maintainable as: | case 'installcontents' : FileInstallationFilter::setParent($this); return new v2Iterator_File( new FileInstallationFilter( new v2Iterator_FileContents( $this->_packageInfo['contents'], 'contents', $this)), RecursiveIteratorIterator::LEAVES_ONLY); case 'packagingcontents' : PackagingIterator::setParent($this); return new PackagingIterator( $this->_filelist); | both because it's shorter and less chance of mistyping the redundant namespace information. > > <?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; > > namespace PackageTwo > > class SomeObject { > public function doSomething() { > $obj = new FooBar(); // PackageOne::FooBar this will resolve as either PackageTwo::FooBar or internal class ::FooBar. If you had done import PackageOne::FooBar; it would resolve properly. This is a parse error, you can't redefine FooBar: <?php namespace PackageTwo; import PackageOne::FooBar; class FooBar {} ?> The beauty of import is that you can do this: <?php namespace PackageTwo; import PackageOne::FooBar as Happy; class FooBar extends Happy {} ?> and remove collisions, or you can do: <?php namespace PackageTwo; class FooBar extends ::PackageOne::FooBar {} ?> Greg > $driver = new Driver(); > } > } > > class Driver { } > > ?> > > Now, what happens when there's PackageOne::Driver in addition to > PackageTwo::Driver? The routes as I see them are: > > 1. Uses PackageTwo::Driver as SomeObject is within PackageTwo. > 2. Uses PackageOne::Driver as it was declared first > 3. Never runs as class Driver caused a fatal error > > Part of the benefit of namespaces/packages is that you can keep object > names extremely generic without worrying about name collisions. > Having two Driver, Abstract, Parser, etc., etc. classes in different > packages will not be that unlikely. If we import a package into the > current scope we have to worry about clashes, no? > > All that said,I think its too early in the release cycle of PHP to be > adding speculative features. Until there's at least a beta PHP 5.3 > release, what ends up in the actual release is up in the air with how > it behaves is even more so. > > -Travis