On Fri, Aug 3, 2012 at 3:07 AM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> 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)... > > I didn't mentioned renaming or removing methods - only the ability to add new methods, constants and class members into existsing classes. If we're only talking about adding methods - such problem won't be occur since if you're calling an extension method you should know that it exists. for example - I can get the same problem if I'm using the magic methods - you could say that because the magic method work in some way that invoke a method one should run xdebug and trace where the method goes and why it's work the way it's work. > 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. > I've brought up other languages because I think that this is a pro when comparing them to PHP that we should integrate into PHP too - for example, if we're talking about C# "lock" keyword - although it's quite helpful I don't think it should be implemented in PHP. Both languages I've brought for comprasion - C# and Objective-C got interfaces (C# got very rich OO). Yes, as long as I know they don't support autoloading but I don't see any problem with that because the autoload should remain the same. So I'm against adding functionality that makes implementing architectural > flaws easier while doing nothing for good programming practices... > > Anthony > 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.
