At 13:07 10/04/2002 -0700, brad lafountain wrote:
>--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > At 12:46 10/04/2002 -0700, brad lafountain wrote:
> >
> > >--- Andi Gutmans <[EMAIL PROTECTED]> 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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
