Re: Re: aggergate vs MI

At 00:53 09.04.2002, you wrote:

--- "Stig S. Bakken" <ssb@fast.no> wrote: But a class is not defined at runtime, it's only compiled into bytecode that, when executed, declares the class. That's what Zeev means when he says that the difference between compile-time and runtime is not that big. IMHO there is room for both aggregate and MI. We have require and include, not just include? :-) Ok now we are talking :)... I think if aggregate exists then MI is absoulty necessary. but if MI exists then aggregate doesn't necessarly need to exists.

Sure! And keep in mind that when only having MI we only have objects because we allow or instances to have dynamically added members. class A { } $a = new A; $a->b = 'new'; // WORKS! When having aggregation we also have objects because of changing method tables, too. Then why am i not allowed to do the following: class A { } function add($name, $value) {

        $this->$name = $value;   // WORKS!

} $a = new A;

$a->add = add;    // NOT Allowed

$a->add('b', 'new'); This is not possible now BUT this is object oriented code and not only class oriented! And we did not use Aggregation. Aggregation is only a technique to add complete method tables from one class to an object (run-time) whereas MI adds complete method tables from one class to another class. Therefore aggregation is only a specialcase of the above scenario. If the discussion did only came up because someone wanted to have streaming there are three ways out of it: 1) MI 2) aggregation 3) properties and a superclass that has a stream interface with properties (like Borland's CBuilder). 4) Interfaces Option 3 has the negative effect that only classes derived from the defined superclass can be streamed. Option 1 allows to add streaming support for any class at compile time whereas aggregation would allow to add streaming at run time to instances which were never considered to be streamed. Again the 4th option allows to do all without MI or aggregation (that does not mean i dislike MI/aggregation - i like MI+Interfaces). In a mail some hours ago brad already unfolded the main difference: With aggregation you can have d=(a,b) and d=(a,c) while MI only allows d=(a,b,c). marcus

- Stig On Tue, 2002-04-09 at 00:16, Marcus Börger wrote:

Mybe it would make sence to have MI for compile time and aggregation for run time. So we can have good design with MI and prototyping and testing and quick hacks with aggregeation. But doing compile times work with run time methods? marcus At 23:58 08.04.2002, you wrote:

If MI can be emulated using aggregation, how hard would it be to add the syntax for MI to the language, but have it implement it using

aggregation?

Zeev Suraski wrote:

At 00:44 09/04/2002, brad lafountain wrote:

If aggregation is included then i see it is absoulty necessary to

include

MI too.

In my opinion, only one of them (at most) has room in

PHP. Having both is

messy. My personal preference is MI, which is why I prefer tagging aggregation as experimental. Zeev

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

-- 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/