Yahav, On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar <g.b.ya...@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
