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

Stefan Neufeind wrote:

I don't get the point. When e.g. There the user tries to access the data-component "bar" (in Image_Graph, which is currently in CVS), then simply check if a class Image_Graph_Data_Bar is already loaded / present. This should be no problem since PEAR-packages have an "almost" unique name. Only, and only(!), if the class is not yet present you may include 'Data/Bar.php' in this case. So big deal, easy to implement, and extendable - in my eyes. Yes, clearly the problem I have posed is not one that many PEAR users have encountered. This type of issue is more specific to frameworks than to individual applications. Sure, when I'm throwing together a web application, I can include my own driver classes -- from wherever they are located -- and your class (and MDB and Log and probably some others) will either not try to (re)load the class or will supress any errors when trying to include it. And that's great. My point comes into play when you are working within frameworks and you want users to be able to specify their own classes in configuration files (not PHP scripts) that should be used in place of the defaults.

In my ideal world drivers for abstract factory pattern PEAR classes would all implement an interface. Provided that my class implemented that interface (e.g. LogDriver) then I could call my class whatever I wanted and put it wherever I wanted and simply pass some sort of path or path + classname to a PEAR factory() method which would then use my custom driver. That'd be cool, that's all I'm saying. Hans