Re: [Fwd: Re: PEAR framework changes for PHP5]

Jon Parise wrote:

On Wed, Jan 28, 2004 at 11:59:03PM +0100, Tobias Schlitt wrote:

     - But there should be a common base class, i guess, to be able to implement some additional features (e.g. a common versioning method, a common singleton method,...)
   

No, we don't want a common base class. If anything, we want some common, generalized, lightweight interfaces that PEAR classes can implement to extend their functionality. I couldn't agree more here. The common base class only enhances that "all-or-nothing" nature of PEAR. I like the idea of interfaces, but I also think it would be nice if PEAR classes had minimal reliance on PEAR "framework" stuff. Mostly because PEAR isn't a framework ... and now that error can go away and PHP supports destructors, I don't see a justification for any dependencies.

On a related note, I believe PEAR tools would get far more use if they could integrate more easily into other applications. One thing that I think would facilitate this greatly is having a class path convention. I should be able to write (e.g.) my own Log container or MDB driver and specify a full path to that class when using the Log::factory(), MDB::factory() method, etc. My web application does not live in /usr/local/lib/php, and I don't want my container files to have to be copied there so they can be found by the factory method. One solution would be passing the actual path to the file (assumes 1-class per file); a better (IMO) solution might be to have an [optional] array convention -- e.g. array('filepath', 'classname'). I like the array idea because it's kinda like what PHP does for specifying a method to be invoked (e.g. by call_user_func). I've used dot-notation (classpath.relative.to.include.ClassName) for many of my tools because it provides at least a layer of abstraction between filesystem and classname, but that isn't ideal either and wouldn't work for PEAR where filenames and classnames do not match.

- As there are interfaces available now, I guess we should add some templates for common patterns (factory, singleton,...) to the standards.

How would you implement a factory or singleton pattern using an interface? The result would be so highly parameterized that you might as well just write your own full implementation in your base class. Yeah, I don't see this either :) I think the most important thing would be (as I mentioned above) to just establish some standards on things like specifying path to a driver class to use. Some classes support specifying path to class (e.g. PEAR_PackageFileManager) but others don't. I think it could be simplified & standardized, and that this would make these packages extensible in practice instead of just in design.

Hans