Re: Re: revision to the standard that would make me happy

On Mon, Jul 6, 2009 at 3:21 PM, Matthew Weier O'Phinney<mweierophinney@gmail.com> wrote: <snip> > Could you please delineate succinctly, with examples, the serious issues > you've encountered? I've read several long monologues from you, but > nothing that *succinctly* describes the issues you've encountered. Most > of the discussion has been hypothetical in nature, on both sides, and > I'm more interested in code samples. I'm going to ignore rants; code, > not so much. I believe the argument we're facing with the namespace and package naming requirement are pretty well described in Greg's original email. http://news.php.net/php.standards/67 Unless I'm misunderstanding, here's some code that may illustrate the issue — <?php namespace foo\fooframework; class Templates_PluginInterface { } fooframework has now grown too large, we'd like to break the templating system up into a separate package. Everyone using your app has implemented the PluginInterface with: class MyPlugin implements foo\fooframework\Templates_PluginInterface. The question is, how can you break it up into smaller subpackages, maintain BC for everyone that upgrades, without adding a stupid stub class (performance hit)? The proposed standard would require a new package name with a new namespace ala foo\fooframework_templates\PluginInterface, which is very problematic for refactoring a package into subpackages and maintaining BC. By allowing sub-packages to install into the directory of the "parent" package, BC can be maintained without any performance hit. For a real world example, if the previous wasn't real-world enough — MDB2 has drivers for each RDBMS. The drivers needed to have a separate lifecycle. The class named MDB2_Driver_pgsql that was once distributed with the MDB2 package, now has a separate release lifecycle, but installs to the same location and has the same class name == no problems for end users. I believe Greg is asking for minor changes so that this can be achieved in a standard way, or so that this is allowed at the vendor level. What complicates this issue is that with this standard, within one directory, you may have files from different packages or "sub-packages." Did pear2\mdb2\Driver\pgsql.php come from the pear2\mdb2 package, or the pear2\mdb2_driver_pgsql package? Yes/No/Maybe/Depends on what version you're using. This means a tool, such as an installer would be needed to install and manage the installed packages as users wouldn't know which package a specific file might belong to just by looking at the filesystem. In my opinion, this is a minor issue - the installers work well, and every language has something similar. But, this also makes it harder to develop using a method such as a symlink or svn:externals to a directory containing all the files for an individual package WHILE STILL USING the same autoloading scheme as those users that used the installer to manage the packages. To be clear, an autoloader can be written which will allow the files to be loaded, but this adds a performance hit. An alternative to autoloading is adding a file called vendor/mypackage/allfiles.php which lists all of the files in the package to avoid the autoload performance hit (this is required under the PEAR2 standards). SO: One vendor/package_name directory per package, and splitting up a package into smaller ones is hard to do without causing BC or performance issues for your users, and users that develop using svn:externals etc can use the one autoloader to rule them all. OR Change the package naming standard so sub-packages can be installed in the directory of the parent package. This means there are limited/no BC issues with breaking up a package into smaller ones, but end-users must either use an installer to manage their packages with the stock autoloader OR use a slower autoload OR a (faster) allfiles.php file when they use svn:externals/symlinks. It's no wonder people are having a hard time understanding it... I started writing this email four hours ago. Does this correctly sum up the namespace and package naming argument? Are we all on the same page here...? -- Brett Bieber