> > I don't see why this is not a good programming practice, lets get the > following example: > class Member { > public static function create(...) { } > public function update(...) { } > public function remove(...) { } > // ... > } > > now you wish to add, for example, a ban functionally to this member class - > I don't see a good reason to extend this class - it doesn't answer on the > OO concept and just make things complex and even wrong in OOP aspect. > > Another example I thought of is Reflection class - for example, the Zend > Framework got reflection classes that add more features to the built-in > Reflection classes - why shall the base Reflection classes has to be > extended (talking about the concept aspect)? the extending doesn't answer > on the OO concept and the programmers had to extend it only because they > can't add more features to class without extending it. >
This was about as poor of an example as you could have picked. This is not a problem you should be looking to solve at runtime. It is certainly easier to solve this problem correctly via extending or coupling the class. I don't understand why you believe digging into the guts of a class at runtime and adding new methods to it is a good idea or why extending a class in order to add to or alter its functionality in some way is not an Object Oriented concept. Classes should be closed for modification but open for (From SOLID OOP principle Open/Closed principle: http://en.wikipedia.org/wiki/Open/closed_principle). How this makes things *more* complicated is beyond me and you offer no compelling reason to believe that it is. I'm sorry, I see no viable argument to agree with you that any of this is a reason to put runkit (which was -- as stated by the original author of the extension -- nothing more than an experiment that was never meant to be complete for production) into PHP core. I think runkit has some nice uses in situations that relate to unit testing or other special cases, but I see no reason to believe it will prove useful in a production environment, which appears to your primary motive. Since you stated that you would intend for this to be used in framework development and deployment such as in the case of deploying on a shared hosting environment where the user may not have super user rights to install new PHP extensions. This is simply going to indulge users to attempt solving their problems the wrong way. That's a poor approach. I would support further work on the runkit extension in PECL. Sara hasn't done any work on it lately, but I can see how furthering that extension will benefit the community. Just not to the extent that I believe it belongs in PHP core. At least not until its features prove to solve problems for the majority of users that they can not otherwise solve easily with the given language features. None of the aforementioned reasons in your reply indicate this thus far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php