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

Travis Swicegood wrote: > Personally, I find it much more dangerous to leave a class hanging > around in its old location after it is split off into a sub-package than > I do moving it and adding a stub. What happens when I unpack a tarball > or do an SVN checkout that doesn't include all of the sub-packages? The > stub would always (at least until the deprecated code was removed > entirely) be distributed with the original package, providing a clue > that there was a sub-package in the absence of an installer or > package.xml file. As you may not be aware of, the way sub-packages are implemented is to use multiple package.xml files within the same source control library, which renders your point moot - the assumption made that once a sub-package is created, we automatically split it out into another root-level directory is a flawed one. In addition, you are assuming that packages consist exclusively of classes, but this is not true. Packages can consist of PHP source files containing classes, templates, web files, data files, scripts, configuration files, and many other necessary components, all of which will change their installation location when the package name is changed. You can't create a "stub configuration file" very easily, and it is impossible to create a stub XML Schema file. Want a better example? The pear.php.net website was originally one gigantic package. This caused some problems because, for instance, the channel.xml was constantly getting updated, and so running any remote pear command would trigger a "WARNING: pear.php.net has updated its protocols, use pear channel-update pear..." In addition, when doing bugfixing work that broke things, we would have to revert all changes when going back to a previous version. The development paradigm pearweb developers had been using was: * run the website directly from CVS in order to make changes as necessary, package releases of the individual components and tag as they become ready to go. Now, if we have to change this paradigm, the process of setting up a development environment for pearweb would become tremendously more complex. Any change would require a re-install of the portion in question, and when developing, all developers would need to do something like this to ensure they have the whole thing: cd pearweb && cvs update && cd ../pearweb_index && cvs update && cd ../pearweb_channel && cvs update && cd ../pearweb_data && cvs update && cd .. && pear up -f pearweb/package.xml pearweb_index/package.xml pearweb_channel/package.xml pearweb_data/package.xml In addition, if any of the cvs updates had a conflict, the command would stop dead in the middle. Suddenly, we're forced to use a heavyweight build script just to test any change to the website. Currently, the method of testing and release is: cd pearweb && cvs up <make changes to source files> So what benefit do we gain for all of this complexity? Some kind of better abstract organization? On the contrary, it introduces multiple points of failure that were not there before, and have no need to be there. * None of the sub-components can function without the pearweb package (they are not standalone libraries) * They literally cannot be installed without the pearweb package > As for a performance hit, if your mandate is the most speed you can eke > out of the system and one extra class __ extends __ statement > concerns > you, you're using the wrong language. C, C++, or even Java, etc., come > to mind as the place where you should really be doing your coding so you > have complete control over system resources. As I said before, the problem is not the performance hit, it is the fact that it is an unnecessary performance hit. I'm all for performance hits that add value, these are useful. The problem is that there is a better way to solve this that more directly relates to real-world programming that has been quite successful, even if it doesn't match your idealistic view of how we "should" program. > As I stated before, and what was taken out of context to kick off the > thread on pear-dev, this is a request for an exception that's been made > explicitly for the purposes of not changing the way pear-dev has always > done it. There are technical solutions to the problem other than making > exceptions for single projects. The precedent an exception would set is > very harmful to the future of any easily understandable standards document. The problem is not (as you state) that this is the "way pear-dev has always done it" but that the way pear-dev does it is not the way it was always done in pear-dev. It is probably before your time, so you don't remember the bad old days of PEAR when splitting into subpackages while maintaining BC was not a viable option. Before things were done this way, there were two ways things were done: 1) arbitrary BC breaks 2) bloating packages Neither of these were successful in managing requirements of refactoring, and so the innovation of subpackages was introduced to solve them. The standard you're proposing is a step backwards, and will encourage either never splitting up the package because of the annoying pain of renaming and creating stubs, or arbitrary BC breaks. Also, the change I'm proposing is minor, not a colossal complex revision. I am saying that instead of forcing this directory structure: pear2/ package1 package2 package1_subcomponent package1_another_thing it allows developers *at their discretion* to decide that optional sub-components can remain within their parent package: pear2/ package1 package1/subcomponent package1/another/thing package2 Is that really so terribly difficult to understand that it kills off the future of any easily understandable standards document? Greg