Re: [PHP-PEAR] Re: [phplib] Re: [PHP-PEAR] PHPLib and Pear merge

In netuse.lists.php-pear you write:
>1. PHPLib's db abstraction uses _one_ *light* class, which is
>   simply should be extended to use it (extended class must
>specify only the db engine to use and connection parameters to
>work). To use it there should be only _one_ object of an
>extended class initialized (no db connection object, no result
>object of PEAR::DB, etc ...). Some days ago you said that PHP
>OOP handling sucks. That is. I guess such a large class
>hierarchy as PEAR::DB could not stand the performance penalty
>of its over-organization.

When the PHPLIB project started, it was around the time of the
PHP 3 release candidates. Boris Erdmann and I found the PHP 3
object capabilities to be very limited, basically syntactic
sugar for "hashes with functions". Also, there were no
references or pointers, a requirement when working with OOP
properly.

We decided to use classes anyway, because we needed to keep our
global namespace clean and wanted some kind of packaging for our
functions. PHPLIB is not an OO library despite the fact that
everything but page.inc is packaged into classes. PHPLIB uses
classes only for two purposes: packaging and customization.

PHPLIB itself uses classes, because it is the closest thing PHP
3 had to Perl packages. And PHPLIB users use classes to
customize the original PHPLIB packages to suit their
requirements without the need actually change the PHPLIB
distributed files, thus enabling you to cleanly mix and match.

Despite that limited use of classes, Boris and I ran into a
number of problems with the PHP 3 release candidates at that
time, generating over 50 bug reports mostly in the memory
management area. I believe we are responsible for at least two
of the six PHP 3 release candidates. :-)

While PHP has come a long way regarding its handling of objects
since then, I still believe that the PHPLIB way of "use objects
everywhere, but in a very conserative way", is still valid.

Kristian