On Fri, Aug 3, 2012 at 5:46 AM, Sherif Ramadan <theanomaly...@gmail.com>wrote:
> >
> > 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 can't agree with you, and you can see that other languages such I've
described take advantage of this idea. you can always solve ideas with many
ways - we're looking for making things easier and I think that this ability
can answer that.
Okay, so my examples is one of the basic things I thought about as a
frameworks and CMS developer.. but I do see other pros to this - such as no
need to cast returned object to your own type if you should not extend it
(because of OO concept), or for example it'll make easier to create hooks
for MVC controllers, or for example you got an HtmlHelper class that you're
using in your views - you can't add your own helper function unless you're
providing a logic with __call that loading a third-party classes from a
directory / looking for registered classes and then searching for the
method and invoking it - I think that the extension feature is really
useful in cases like that.
> 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.
>
> Because extending and inheritance in OO is not something that should be
done when you wish to add methods to the same object but add methods and/or
properties to new object - if you're only create, fore example, your own
ReflectionClass just to add some new methods that could be added to the
same base class without change its meaning - it's not follows
the inheritance concept.
> 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.
>
It's okay :) that's why I've started that discussion before starting to
integrate runkit within the language and create a wiki page for the feature.
>
> 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.
>
Users could solve their way anytime using wrong approach and we can't stop
extending the language because user may use a feature in the "wrong way"...
for example, I saw many times that users use static and encapsulation
concept wrong - we can't do anything about it, I don't think this is a good
point... My point of view is - "if the user do know how, and in which cases
to use it" - will he/she'll benefit from it enough to add it into the core"
- I think that in this case yes.
> 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.
>
It's remind me the discussion of Generators...
Lets take for example the lambda functions - you can solve your problem
easily enough in the given language (using create_function, eval..) but
it's still a great feature in the language (This is my opinion though...)
Although I can't say for sure that it can help for the majority of the PHP
developers, I can say that there's many developers who use frameworks in
order to develop their applications and I think that these frameworks will
take advantage of this feature and will result in that these many developer
will use them too - for example, like I've suggested above - extending
controllers, adding their own function to existing classes without
overriding them etc.
Maybe I'm wrong when comparing with other languages and mainly with
ASP.NET(C#) since they've used it for web proposes but I did saw many
classes that
used this feature and personally really like it.
If my vote still counts (I was somehow involved in the creation of runkit
> at one point (-: ), I say the same: extension is fine. Don't monkeypatch
> production.
I've suggested to improve the language itself with some of the features in
runkit, not to copy and use it as is.
