Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61984
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANVTSm6sdf-OSzZRYSb-qYm+csY+simeqekBnHM6Bx90-oD9EA@mail.gmail.com>
References: <CANVTSm5g0FWqe=HaJTutniLYOj19rp5twOzF0jti0y3iEsnWEg@mail.gmail.com>
	<CAKOpQSwSwseEoxDYzpfwkgk-azxKyAVq=hRJa=P=v8qg7VAJ_A@mail.gmail.com>
	<CAFt2z-nHB91SSNaJpn_K1-OzWtC7=W4WUUKCBQYHbb+kbeKsBg@mail.gmail.com>
	<CAESVnVpXTza67aOOeFqJ72F3=nxe3vTRHWkkzZNc+FChhCbwhg@mail.gmail.com>
	<CAPwsocEbXSVSc-aDUQjjaADF3-pNLQF=Danxo67GE5oZpCY-5A@mail.gmail.com>
	<CAESVnVrMwdqcofHt-xz7rkAoaRv=DOcNagqdnPajicteD4eEfw@mail.gmail.com>
	<CANVTSm5HVa8Z5eCZf4oKBBJz8Pqhkj_hMnr5WkiX1e5z0=uizw@mail.gmail.com>
	<CAAyV7nGRBWPZYWw6E8m+UnO2RV5xgXdg3z8JG3epoWy0gKUWsw@mail.gmail.com>
	<CANVTSm6sdf-OSzZRYSb-qYm+csY+simeqekBnHM6Bx90-oD9EA@mail.gmail.com>
Date: Thu, 2 Aug 2012 22:46:00 -0400
Message-ID: <CAL+t6cFR4OprN2OE_=HSr5c7cJXqn0XsaEcSOAJ1WinDsVJSqQ@mail.gmail.com>
To: Yahav Gindi Bar <g.b.yahav@gmail.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Sara Golemon <pollita@php.net>, Leigh <leight@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Add runkit to PHP Runtime
From: theanomaly.is@gmail.com (Sherif Ramadan)

>
> 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.