On Tue, 2002-04-09 at 16:47, brad lafountain wrote:
>
> --- Lauri Liinat <[EMAIL PROTECTED]> 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.
>
>
> Im also a -1 on interfaces. They don't fit into php nicely. Besides interfaces
> don't let you "include" implemntation.
>
> Ok... so where do we go with this thread.
>
> a vote?
>
> plain ole MI..
> class a extends b,foo,bar;
>
> or a new keyword aggregates...
> class a extends b aggregates foo, bar;
>
>
> The first is less confusing but doesn't really make sence as far as describing
> the relationship OO.
> The second is more confusing but really describes the relationship between the
> objects.
>
> here are some examples...
>
> class serializable
> {
> function serialize()
> {
> return implode(":", $this);
> }
> }
>
> class stack aggregates serializable;
>
> $stack = new stack();
> echo $stack->seralize();
>
> ...
> class mythread extends thread aggregates runnable;
>
> ...
Please note that _real_ aggregation has an _instance_ of the aggregated
class in the object you apply the aggregate to. The current PHP
implementation shortcuts this though, and is in effect runtime multiple
inheritance.
Andrei did put a lot of work into the current implementation, and it is
faster than the "real" thing.
I think an "aggregates" statement during class definition like you
suggest above could work.
I don't think interfaces have anything to do in PHP due to its
loosely-typed and runtime-dynamic nature.
If PHP does get a form of MI, it should share implementation with
aggregate, to avoid tiny but annoying semantical differences. :-)
- Stig
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
