Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61980
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANVTSm5HVa8Z5eCZf4oKBBJz8Pqhkj_hMnr5WkiX1e5z0=uizw@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>
Date: Thu, 2 Aug 2012 20:07:50 -0400
Message-ID: <CAAyV7nGRBWPZYWw6E8m+UnO2RV5xgXdg3z8JG3epoWy0gKUWsw@mail.gmail.com>
To: Yahav Gindi Bar <g.b.yahav@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Leigh <leight@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30667c0d9cef1d04c65151d2
Subject: Re: [PHP-DEV] Add runkit to PHP Runtime
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf30667c0d9cef1d04c65151d2
Content-Type: text/plain; charset=ISO-8859-1

Yahav,

On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar <g.b.yahav@gmail.com> wrote:

> I do think that some of  the runkit features should not be included in PHP
> core but I wish to focus on extending classes with extension methods,
> constants, traits and members.
>
> Just like all other complicated and powerful features in PHP, one should
> use them with a good reason and when he/she knows exacly what he/she is
> doing - but we should provide the tools and ability to do that - that's
> what I think..
>
> I see the main usage for extension methods within frameworks and other big
> applications that allows third-party integration such as CMS, forums
> software etc. - in such kind of applications, extension methods can be very
> useful, and you can take for example the many usage of this in
> ASP.NET<http://asp.net/> applications
> that uses this concept (even if we'll take Objective-C, you can find on the
> net many implementation of features for UI controls that was added via
> extension method since there's no OO based reason to create a child class -
> for example, many added method for setting background image to UIView type
> object as an extension method).
>
> I don't think that this features should remain in PECL package (that's the
> reason I've created this discussion) since frameworks and software that
> third-party users will use should not relay on PECL packages... many users
> who use frameworks and CMS use shared hosting enviorment and don't have
> permissions to install PECL packages - if we want to bring this feature and
> give such scripts to use this features we shall deeply integrate it to the
> core of PHP - just like I've suggested above, I think that a new keyword or
> syntax should be introduced for this usage.


I wholeheartedly disagree towards this line of thinking. The ability to add
and rename functions/methods dynamically to already defined constructs is
going to do nothing but cause problems. For example, let's say that you're
working with a class, and using it in one area of your application. Then
you want to go re-use it in another application. All of a sudden, it stops
working for non-obvious reasons. As it turns out, it was because the class
was modified in some corner of the code elsewhere on the page. And the only
real way to find that out is to step through it in xdebug to see where the
trace goes (or dig through reflection to try to take a stab in the dark)...

Now, I know you brought up other languages. I'm glad you did. PHP is not
other languages. Other languages have first-class meta-classes that let you
directly do things like this to. But they also don't have support for
contract based programming (interfaces) or things like autoloading (both
which are problematic with this approach). So unless we wanted to drop
interfaces (big -1 from my book) or implement a first-class meta-class
structure for all classes (huge +1, if done right), then this is only going
to hurt things.

Besides, there are ways to solve this problem today. You can implement
decorators and bridges to solve this problem in a reusable and easy to
understand way. Sure, it makes it hard to do dirty things (like insert a
function in a parent of an inherited object), but you shouldn't be doing
those things anyway (if you find a need for something like that, you have a
*major* architectural flaw).

So I'm against adding functionality that makes implementing architectural
flaws easier while doing nothing for good programming practices...

Anthony

--20cf30667c0d9cef1d04c65151d2--