parent::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. On 5/18/05, Nicholas Telford <[EMAIL PROTECTED]> wrote: > Wez Furlong wrote: > > >Just like extending any other built-in class, you need to be careful > >to not override built-in methods that either exist now or may exist in > >the future; you can very easily burn yourself 6 months down the track > >this way. > > > >It's generally a bad idea, and definitely something to avoid if you > >are building a class library. > > > >You have now been warned that the traffic is dangerous; if you want to > >go play in it, it's your choice :-) > > > >--Wez. > > > > > The same could be said for using an external Framework or library > (except that they'd have the luxury of protecting important methods with > "final"). > > I take it parent::method() works with built-in classes? > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
