--- 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.
BTW:
Have you looked at my patch to handle method calls differently?
- Brad
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
