I totally agree with point 2). However on point 1, MI allows you to inherit from non-abstract classes, which causes problems (I will send an email later tonight about those problems, my laptop crashed when I sent it this morning). If there was enforcement for allowing only abstract classes to be multiply inherited (which admitelly would start being hell from programmers), then it would look like interfaces (which are supposedly more understandable by programmers..uhuh). Point 2, however would prohibit this enforcement, so we're back to square one.
I like aggregation because it kind of forces programmers to modularize components of classes. When MI is used, we often see a mix of functions that reference many classes inside the class that extended the other classes (are you confused yet?). Aggregation, however, is kinda hard to read by people that don't really understand object oriented programming and just refer to classes as a language convenience but don't go beyond it and really use classes as they should be, extendable objects or reusable objects (and not both at the same time). I like clean code, and I think aggregation would be cleaner, but it could be a burden, and we want people to use php. Tough decisions :) Fab. >From: Zeev Suraski <[EMAIL PROTECTED]> >To: "Lauri Liinat" <[EMAIL PROTECTED]> >CC: <[EMAIL PROTECTED]> >Subject: Re: [PHP-DEV] Re: aggergate vs MI >Date: Tue, 09 Apr 2002 19:25:18 +0300 > >You described my thoughts *perfectly* - thanks :) > >Zeev > >At 16:26 09/04/2002, Lauri Liinat wrote: > >>hi all, >> >> > I'm personally in favour of having MI in PHP, with the serious >>alternative >> > being interfaces. I have failed to understand what interfaces would >>mean >> > in a language such as PHP, though, while I can see the clear hands-on >>use >> > for MI. >> >>1) the whole concept of interfaces as they are in Java can be thought of >>as a *subset* of the functionality of MI (when combined with abstract >>classes), and that being said, it is obvious that everything that can >>be done with interfaces, can also be done with MI by inheriting >>from abstract classes (as you would in C++). but with MI you can do >>even more - you can multiply inherit implementation. so, why cut off >>possibilities? i agree with Zeev here, MI is definitely superior to >>interfaces. >> >>2) interfaces lose their meaning in a loosely-typed language such as PHP, >>which is so dynamic that no attribute nor method declarations are >>required in order to write code around an object. interfaces are nothing >>but >>abstract classes, which do not allow implementation or instantiation. >>but you do not even have abstract classes in PHP - the compiler doesn't >>prevent you from trying to call a method that isn't there... the error >>pops up >>as late as at runtime. in PHP, object interfaces only exist in the heads >>of the >>programmers, not in the compiler, they just aren't there. this way, it >>doesn't >>matter if programmers draw interfaces on sand using UML in order to >>communicate with each other, PHP compiler does not need to know about >>interfaces. therefore, interfaces really do sound kind of silly in the >>context >>of the PHP language. >> >>regards, >>lauri > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
