Re: PEAR_DelegateOwner Part Deux

I think I went down the wrong path. I did not intend to merge with PEAR_Autoloader, or even replace it, as PEAR_DelegateOwner can and should stand on its own as a class. If, however, replacement is the direction, I propose this: Let PEAR_Autoloader be a subclass of PEAR_DelegateOwner, and then the old API can simply map to that of DelegateOwner. The only problem is that PEAR_Autoloader deals with autoloading code, which is not the purpose of PEAR_Delegate owner. Nevertheless, the old API could wrap the new PHP 5 autoloading mechanism. On 28 Jan 2004, at 10:22 AM, Martin Jansen wrote:

On Tue Jan 27, 2004 at 05:1118PM -0500, lingwitt@bellsouth.net wrote:

The capabilities of the PEAR_Autoloader are a subset of those of PEAR_DelegateOwner. They are otherwise much different in purpose, though the latter can be used like the former.

The key point might be if a) the performance of PEAR_Autoloader will suffer from the "merge" with the delegation code? b) you are able to keep the API of PEAR_Autoloader, so that backwards compatibility is preserved? --

    - Martin                           Martin Jansen
                            http://martinjansen.com/