Re: Re: aggergate vs MI

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 <zeev@zend.com> To: "Lauri Liinat" <lauri.liinat@microlink.ee> CC: <php-dev@lists.php.net> 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