--- Zeev Suraski <[EMAIL PROTECTED]> wrote:
> At 01:51 09/04/2002, brad lafountain wrote:
> >But do you see my point that having ONLY aggregate means that in 90% of the
> >case where people will use it its probally a bad idea. They are only using
> it
> >becuase of the lack of MI. How does aggregation solve overwriting methods.
>
> Yes, I see the point...
>
> >but i still don't like this... there are cleaner ways around that by using
> >members and/or MI.
>
> I really don't know - as far as I know, aggregation is really not about
> runtime, but about 'has a', vs. 'is a'. When you have 'hard' compiling,
> i.e., a phase that turns source code into a binary component, aggregation
> helps keep a loose relationship between objects, but it's still done in
> compile time of the new, 'derived' or constructed class:
Yeah i guess i really didn't understand aggregate. from the implemnation of it
i was assuming that it was runtime-inheritance. after reading one of the links
and understanding a little more what the term aggregate really means I not sure
what to do here then.
I think i read on that same post that noone can really think of a true MI
example that makes sence. I guess i never really thought of that ither. Every
example i can quickly think of in my head is a 'has a' relationship. But using
MI will 'emmulate' 'has a' relationships but truly doesn't define the
relationship. Maybe we need compile time aggregation. But sometimes that
doesn't even make sence.
// doesn't make sence
class wood;
class knob;
class door extends wood
aggregates knob;
$door = new door();
$door->turn();
// but this does
class wood;
class knob;
class door extends wood
{
var $knob;
}
$door = new door();
$door->knob->turn();
So i guess what im saying if aggregate() is a keeper then we need a compile
time equlivant.
but doing something like i have above where aggregate is a keyword and you can
define multiple aggregation objects off of it. how would it really differ
(implemntation wise not design wise) from MI. I really dont think they would be
different at all. So providing syntax like
class a extends b aggregates foo, bar;
makes reading really really easy but might be more confusing than doing
class a extends b, foo, bar;
So i would be totally +1 on ither
class a extends b aggregates foo, bar;
or normal MI.
- Brad
>
> class aggregated_class {
> var $inner_object;
>
> function aggergated_class()
> {
> $this->inner_object = new inner_class();
> }
> function inner_method()
> {
> return $this->inner_object->inner_method();
> }
> }
>
> Zeev
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
__________________________________________________
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
