Wez Furlong wrote:
Unless the developer of said library realised this problem and decided to prefix all his/her methods with something unique :-Pparent::method() should work, but the point is that if you add a foo() method in a class that extends PDO, at a time where there is no PDO::foo(), and you make it work in a particular way, and 6-18 months later, when PDO::foo() gets added and does something totally different. Now, someone else is consuming your library and hasn't yet used your foo() implementation, they read the PDO manual and spot the official PDO::foo() method and wonder why it doesn't work right.
Even more of a headache is that drivers can magically add methods to the namespace; different methods may be present on an instance (via call overloading) depending on which driver is in use. These are not visible via reflection.
This is a classic namespacing problem. We've solved this internally be forcing drivers to prefix their methods with the driver name. Any non-prefixed method names are reserved for future use by PDO.
If you don't follow this guideline, your code is officially broken :-)
--Wez.
I understand what you're saying, and it is a bit of a problem, however, it's something that other Object-Oriented languages must also suffer when users decide to subclass a built in class, or even one from an external library. In fact, this problem would be present anywhere where someone would be subclassing a class that is not under their direct control.
So I guess the moral of the story is, it's possible, just be careful with method naming :-)
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
