At 00:53 09.04.2002, you wrote:

>--- "Stig S. Bakken" <[EMAIL PROTECTED]> 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/


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

Reply via email to