Re: Proposal for aggregation vs. MI

At 13:07 10/04/2002 -0700, brad lafountain wrote:

--- Andi Gutmans <andi@zend.com> wrote: At 12:46 10/04/2002 -0700, brad lafountain wrote:

--- Andi Gutmans <andi@zend.com> wrote:

Hey guys, I still haven't finished reading the looooooong thread on

aggregation vs.

MI because you guys write so much :) I would like to make a proposal for a solution which I think would fit

PHP

very nicely. My main concern with MI is that there are many problems with it

including

namespace clashes and other problems most of you are probably familiar with. I think trying to work around and find solutions for all of these would make a PHP implementation of MI extremely hard to use and would

move

away from the spirit of PHP which is powerful simplicity. What I have in mind is something similar to aggregation (in the

original

C++ sense which means a "has a" relationship) but improve it with an auto-proxy mechanism. Basically what I'd like to have is something like: class a aggregates b, c {

      ...

}

I did suggest this method already.

Told you I didn't read all Emails :) :)

But it really doesn't address the naming clash class b { function print() { } } class c { function print() { } } class a aggregates b, c { } $a = new A(); $a->print(); you said in the order they were aggregated. but what if i really want to

call

c->print(); would i do something like this. $a->c->print();

I was thinking that we could have an explicit way of calling the right one. hmm what would this look like? $a->c::print(); i guess that's not that bad. and its kinda consistant but i do like $a->c->print(); too.. and would we treat member of b and c the same way $a->member_of_c = false; then the collision again.... $a->same_name_var = false; $a->c::same_name_var = false; $a->b::same_name_var = false; or $a->c->same_name_var = false; $a->b->same_name_var = false; I do think that this by far the best solution because as I said it's extremely simple and it doesn't get us into most of the deep issues the other solutions get us into. I think in real life coding it will work extremely well. For each proposal you can find problems.

and how does this consern serilization. Would it need to be change do designate which objects are aggregated?

Each object would know which objects it aggregates so I don't see a real big problem here. I guess potentially there are always problems when serializing nested objects. I wasn't thinking it would be a problem but the serialization could would need to change to handle this type of change.

Sure it needs to be changed.

BTW: Have you looked at my patch to handle method calls differently?

Yes and I don't like it. I haven't had time to do timings yet. I was very busy and will try and do it in the next few days. Andi