Re: revision to the standard that would make me happy

Travis Swicegood wrote: > Hey Greg; > > On Jun 30, 2009, at 10:33 AM, Greg Beaver wrote: > >> A new package designed from scratch may choose to start out with split >> up packages, in which case the original naming standard could be used. >> >> The separation of packages is still supported (each package gets its own >> subdirectory), and the fact that sub-packages are in the same directory >> as their parent package is never a problem because they were designed to >> be this way in the first place. The only time having 2 packages in the >> same directory could be an issue would be if they are completely >> different packages. > > Here's the line in the above paragraph that bothers me: > >> ... and the fact that sub-packages are in the same directory >> as their parent package is never a problem because they were designed to >> be this way in the first place. > > The problem with this is that the only thing that's ever considered > this as realistic is full-fledged, distribution repository management > systems (apt, yum, etc.) and the pear/pyrus installers. Every other > mechanism for distribution "packages" (modules, components, libraries, > apps, whatever you want to call them) assumes one directory one package. > > That said, your thought process is slightly flawed. You're trying to > come up with an answer to a technical problem in a coding standard. > BC is up to each package maintainer and/or vendor level. For example, > PEAR can't force Zend Framework or Cake to adopt their same policies > on BC breaks. Removing the one package one directory structure > removes makes life harder for those working with version control > (i.e., the *vast* majority of us working in the field) simply because > PEAR has very strong BC rules. Instead of looking at it from the > standard, look at it from the code back. > > PEAR says that once a stable release is reached you can't change the > API in a BC-breaking way. In your scenario where two driver packages > need to be spun off into their own (ignoring the fact that the > collective should have pushed for this prior to a stable release > anyhow) the fix is simple: create stub classes that delegate to the > new driver. The new blah package would add a required dependency on > the new sub-packages and BC is still maintained. To top it off, > developers are given a place to include a deprecated warnin providing > a convenient way to start a deprecation cycle, something along the > lines of a code having to be marked as deprecated for N releases and > triggering errors for X releases before it can be entirely removed. > > That's neither here, nor there, however. It's something for the > individual frameworks and libraries to figure out on their own. The change I'm proposing does *not* force other vendors like Zend Framework or Cake to do anything to their package design. On the contrary, the existing draft standard forces PEAR to conform to what the others do with BC. I am actually suggesting that perhaps the definition of "package" can be expanded to include a PEAR-like model where one can install a package via: pear install PackageName and actually install PackageName and its required subpackages PackageName_Sub1 PackageName_Sub2, etc. As far as the user is concerned, this is all 1 package, but the user has some more flexibility over how to upgrade the individual sub-components of this package. Obviously, a user who is manually downloading http://pear.php.net/get/PackageName-1.2.3.tgz http://pear.php.net/get/PackageName_Sub1-1.0.0.tgz and http://pear.php.net/get/PackageName_Sub2-1.0.1.tgz will see these as 3 packages, but turning your example back on you, the *vast* majority of us using PEAR in the field don't do this, and have no plans to do this. What, exactly, is the point of this standard? I thought it was designed to standardize a few important things 1) mapping of class name to directory location so that a standard autoloader can be used for all projects (not affected by my suggestion, class name still maps to path just fine) 2) best practice naming of abstract structures (interfaces, exceptions, abstract classes) but it appears that the standard is also designed to do the following: 3) make it required that all vendors support the possibility of their packages as svn:externals/git submodules This is important to state explicitly (and is the thing that I strenuously object to requiring in the standard), as the truth is that the next revolution in source control could obsolete this requirement (i.e. when external repositories support merging directories so that in effect single files can be imported from exteranl projects). In addition, #3 makes the assumption that it is always a good idea to do this when in fact many useful packages actually require some configuration to work. Designing a standard around this idea simply limits the standard to those assumptions. Also, do think twice before writing things like "your thought process is slightly flawed." It does not imply a strong sense of respect for the idea proposed or more importantly the person proposing it, which can easily lead to flame wars or the dreaded "bike-shedding." Greg