Re: Proposal for aggregation vs. MI

From: Date: Wed, 10 Apr 2002 20:11:32 +0000
Subject: Re: Proposal for aggregation vs. MI
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-82507@lists.php.net to get a copy of this message
At 13:07 10/04/2002 -0700, brad lafountain wrote:
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..
As I mentioned I'm not even sure this is needed.
and would we treat member of b and c the same way
Nope. We would only do this for real methods. I think this is good enough and gives a clear interface! Andi
$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/


« previous php.dev (#82507) next »