Jared Williams wrote:
PS: An real-life example from those wo prefer the old
behavior would be
nice ;-)
-soenke
Yes, I having a hard time imaging one, other than some quick fix.
I'd much rather have some decent refactoring tools.
The fact of the matter is you do not need the old behaviour (just like
you do not need to new behaviour either) to wrote code.
"Proper" planning would enable anyone to steer clear of having to
rewrite the signature of a method in such a way that it becomes
incompatible with the parent. However glue script languages are about
rapid prototyping and less about planning. Obviously planning is good
and important, however it requires a lot of effort to do it in a clean
OOP way. Especially since I am quite certain that for a lot of
situations clean OOP (as in maintaining the is instance of relationship
for every method) is not necessary or even relevant.
So here is a real world example. Of course it will probably get a lot of
PEAR sucks anyways flack, but so it goes.
The base PEAR class implements an incredibly flexible raiseError()
method that is overkill for most classes. In proper OOP you have to make
the parent implementation the lowest common denominator and add
flexibility (as in additional parameters) inside children. For whatever
reason this was not done. Changing the signature later on was
effectively not feasible as that would have broken BC. So in PEAR::DB
(as well as MDB and MDB2) this method was overwritten with a simpler
signature.
Of course like I mentioned in a post before, an alternative that will be
proper OOP would have been to add a simpleRaiseError() or whatever
method that simply calls parent::raiseError(). However this meant
cluttering the API with the parent method and this new method. So the
"clean" solution would have resulted in clutter.
In all the years of PEAR::DB etc useage I have not seen a single issue
that resulted over this, or even anyone report and issue over this until
it was disallowed in PHP CVS and someone told me that MDB2 doesnt work
with HEAD.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
