Re: [PHP-DEV] Re: aggergate vs MI
--- 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
Re: [PHP-DEV] Re: aggergate vs MI
On Tue, Apr 09, 2002 at 12:11:11AM +0300, Zeev Suraski wrote:
Having both makes very little sense. Compile-time vs.
run-time in PHP doesn't make any real difference as far as
functionality goes, because the stages are linked together
immediately.
Not the point here. In
class D extends A, B, C ...
the class names are static (determined at compile-time). In
$classes = array(A, B, C, D);
$d = new Object; // Object is an empty class.
foreach($classes as $c) {
aggregate($d, $c);
}
the class names are variables, and in fact, aggregate could and
should take an array as well as a string as the second parameter
in the first place.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
On Mon, Apr 08, 2002 at 02:44:14PM -0700, brad lafountain wrote:
for($i = 0;$i 1;$i++)
{
$d = new a;
aggregate($d, b);
aggregate($d, c);
$d-method();
}
That is
$d = new A;
aggregate($d, array(B, C));
for ($i=0; $i1; $i++) {
$d = copy $a;
$d-method();
}
in PHP, with aggregate() taking the array syntax suggested by
me, and copy being to instances what new is to Classes (copy
constructor). As you can see, it is a direct match to your code
for($i = 0;$i 1;$i++)
{
$d = new d;
$d-method();
}
(but $d is already initialized properly in my example, and then
copied, whereas you run 1 initializations).
I currently am trying to talk my company to use php over
java. This is a huge project. The company i work for has 22000
employees and probally 500-1000 developers across us (mainly).
And in desiging our classes i can see where i could use MI.
and im not about to go and tell all 500 developers that
evertime you create an instance of x you need to aggerate y.
You don't. There is no need.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
I'm not saying you can't find a use for it, I'm sure you can. I'm saying
that aggregation the way you use it is something that at least I have never
seen used anywhere else before. I've never seen an object oriented program
that is written without knowing anything about the classes it's going to
work with, it doesn't make too much sense... or does it?
In your example, I understand what it does, but I don't understand what's
the advantage over MI in this case.
At 11:53 09/04/2002, Kristian Koehntopp wrote:
On Tue, Apr 09, 2002 at 12:11:11AM +0300, Zeev Suraski wrote:
Having both makes very little sense. Compile-time vs.
run-time in PHP doesn't make any real difference as far as
functionality goes, because the stages are linked together
immediately.
Not the point here. In
class D extends A, B, C ...
the class names are static (determined at compile-time). In
$classes = array(A, B, C, D);
$d = new Object; // Object is an empty class.
foreach($classes as $c) {
aggregate($d, $c);
}
the class names are variables, and in fact, aggregate could and
should take an array as well as a string as the second parameter
in the first place.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
COM!
COM uses all of this kind of stuff (implemented in various ways through
inheritance, aggregation via template classes, proxies and delegates).
And why go to all this trouble? So that your code can work with code
written by third parties that have no knowledge of your code, nor yours
of their code.
So it's really just interfaces then, but more flexible because you
are not limited to just implementing interfaces.
--Wez.
On 09/04/02, Zeev Suraski [EMAIL PROTECTED] wrote:
I'm not saying you can't find a use for it, I'm sure you can. I'm saying
that aggregation the way you use it is something that at least I have never
seen used anywhere else before. I've never seen an object oriented program
that is written without knowing anything about the classes it's going to
work with, it doesn't make too much sense... or does it?
In your example, I understand what it does, but I don't understand what's
the advantage over MI in this case.
At 11:53 09/04/2002, Kristian Koehntopp wrote:
On Tue, Apr 09, 2002 at 12:11:11AM +0300, Zeev Suraski wrote:
Having both makes very little sense. Compile-time vs.
run-time in PHP doesn't make any real difference as far as
functionality goes, because the stages are linked together
immediately.
Not the point here. In
class D extends A, B, C ...
the class names are static (determined at compile-time). In
$classes = array(A, B, C, D);
$d = new Object; // Object is an empty class.
foreach($classes as $c) {
aggregate($d, $c);
}
the class names are variables, and in fact, aggregate could and
should take an array as well as a string as the second parameter
in the first place.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
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
Re: [PHP-DEV] Re: aggergate vs MI
COM's a hack, though. It really is.
COM's entire design was derived from the need for binary compatibility
between components, which plays absolutely no role in PHP. They had to go
through hoops in and some real ugly hacks to achieve their goal (which they
have, quite successfully, I have to say). What they did in ATL basically
does a fair amount of magic to give you the ability to inherit code with
COM's strict binary compatible model...
COM's aggregation is implemented in userspace, even though it's very
standard (through QueryInterface). A PHP equivalent would be providing a
getSubObject() class, that would simply return an inner object, that you
can use directly. Aggregation is typically very very simple, and rarely
requires any 'inner' modifications of the object's layout.
I'm personally in favour of having MI in PHP, with the serious alternative
being interfaces. I have failed to understand what interfaces would mean
in a language such as PHP, though, while I can see the clear hands-on use
for MI. Can you explain how you envision interfaces as useful constructs
in PHP, and their advantages over MI, considering the fact all of the
binary compatibility issues don't apply?
Zeev
At 12:09 09/04/2002, Wez Furlong wrote:
COM!
COM uses all of this kind of stuff (implemented in various ways through
inheritance, aggregation via template classes, proxies and delegates).
And why go to all this trouble? So that your code can work with code
written by third parties that have no knowledge of your code, nor yours
of their code.
So it's really just interfaces then, but more flexible because you
are not limited to just implementing interfaces.
--Wez.
On 09/04/02, Zeev Suraski [EMAIL PROTECTED] wrote:
I'm not saying you can't find a use for it, I'm sure you can. I'm saying
that aggregation the way you use it is something that at least I have
never
seen used anywhere else before. I've never seen an object oriented
program
that is written without knowing anything about the classes it's going to
work with, it doesn't make too much sense... or does it?
In your example, I understand what it does, but I don't understand what's
the advantage over MI in this case.
At 11:53 09/04/2002, Kristian Koehntopp wrote:
On Tue, Apr 09, 2002 at 12:11:11AM +0300, Zeev Suraski wrote:
Having both makes very little sense. Compile-time vs.
run-time in PHP doesn't make any real difference as far as
functionality goes, because the stages are linked together
immediately.
Not the point here. In
class D extends A, B, C ...
the class names are static (determined at compile-time). In
$classes = array(A, B, C, D);
$d = new Object; // Object is an empty class.
foreach($classes as $c) {
aggregate($d, $c);
}
the class names are variables, and in fact, aggregate could and
should take an array as well as a string as the second parameter
in the first place.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
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
RE: [PHP-DEV] Re: aggergate vs MI
I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? The only needs of interfaces I see is only for php encoded and closed source (we can called them binaries ;) ). And in this case, I do not like it ;). a+ pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: aggergate vs MI
At 12:12 09.04.2002, Pierre-Alain Joye wrote: I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? The only needs of interfaces I see is only for php encoded and closed source (we can called them binaries ;) ). And in this case, I do not like it ;). a+ pa Would it be so bad allowing closed source? And you are missing the modelling aspect. I think having one of MI, aggregation and interfaces is essential for OO modelling. marcus -- 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
RE: [PHP-DEV] Re: aggergate vs MI
Would it be so bad allowing closed source? I really do not care, but I really appreciate and use only ( for my dev ) open sources products, but that is not the question, and was a joke == ;) :)) I think having one of MI, aggregation and interfaces is essential for OO modelling. I m not a professionnal of OO design, but do not see how interfaces in php will help us during the design phases. Where do you use interfaces during the modelling phase ? If you use pear::db and an interface is available, how do you will use it ? ( no irony in these questions, just interested). pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
On 09/04/02, Zeev Suraski [EMAIL PROTECTED] wrote:
COM's a hack, though. It really is.
What they did in ATL basically
does a fair amount of magic to give you the ability to inherit code with
COM's strict binary compatible model...
COM implemented in C/C++ is, as you say, a hack. When the language
supports COM style interfaces natively, it starts looking less like
a hack and more like something really nice.
I'm personally in favour of having MI in PHP, with the serious alternative
being interfaces. I have failed to understand what interfaces would mean
in a language such as PHP, though, while I can see the clear hands-on use
for MI. Can you explain how you envision interfaces as useful constructs
in PHP, and their advantages over MI, considering the fact all of the
binary compatibility issues don't apply?
In PHP you can think of an interface as being equal to a class (as you
stated above). With MI you do then have a means to do the same thing
(more or less) as interfaces.
There is another point that keeps coming to mind when comparing MI with
interfaces: method name conflicts. Consider this, using an MI approach to
implementing interfaces:
class A {
procedure Run();
};
class B {
procedure Run();
};
class C extends A, B {
// Here we are overriding both A and B's implementation of Run.
// But what if the semantics of A::Run() and B::Run() are different?
// How does the caller know which one it is using?
procedure Run();
};
We could use this syntax to resolve the declaration issue:
class C extends A, B {
procedure A::Run() { // override A::Run
}
procedure B::Run() { // override B::Run
}
}
But what about code that calls those methods?
$c = new C();
$c-Run(); // Which run are we calling?
With interfaces, the caller does not suffer from ambiguities like that,
because it knows which interface it has requested:
$c = new C();
$a = $c-QueryInterface(A);
$a-Run(); // Calling A's implementation of Run.
I can't see how the same could be acheived using MI, unless we adopt
some kind of class casting operator.
Hmmm. So far, it sounds like MI == interfaces when it comes to PHP.
In another email, I demonstrated something like this:
class MyClass implements IFred {
delegate IFred to $fredimpl;
function MyClass($implementation) {
$this-fredimpl = new $implementation; // Could come from anywhere
}
}
For me, based on the above, I don't really care if we have interfaces
or MI, provided that I have some means of explicity specifying which
ancestor class (or interface) I wish to use when making method calls,
and an easy way of doing the above without having to explicitly override
and redirect loads of functions to inner objects (if an object delegates
6 classes/interfaces to inner objects, thats a lot of typing that the
compiler/engine could take care of, and be less error-prone).
I think that language-level support for delegation covers the main uses
of aggregation too, so that would make everybody happy?
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: aggergate vs MI
On 09/04/02, Pierre-Alain Joye [EMAIL PROTECTED] wrote: I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? The only needs of interfaces I see is only for php encoded and closed source (we can called them binaries ;) ). And in this case, I do not like it ;). And yet some of us need to earn a living :-) This would actually benefit PHP, because it could attract bigger, more serious development using PHP. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: aggergate vs MI
Indeed. I would very much like it. It could open new doors to work with partner companies that can extend what ever we supply them with (which is closed source for the most part) Sounds like a smart thing for Zend to implement :-) (As do so many other things ... maybe we should first all work together to extend the day to 30 hours) Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 1:10 PM To: Pierre-Alain Joye Cc: Wez Furlong; Zeev Suraski; [EMAIL PROTECTED]; Kristian Koehntopp; Stig S. Bakken Subject: RE: [PHP-DEV] Re: aggergate vs MI On 09/04/02, Pierre-Alain Joye [EMAIL PROTECTED] wrote: I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? The only needs of interfaces I see is only for php encoded and closed source (we can called them binaries ;) ). And in this case, I do not like it ;). And yet some of us need to earn a living :-) This would actually benefit PHP, because it could attract bigger, more serious development using PHP. --Wez. -- 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
RE: [PHP-DEV] Re: aggergate vs MI
At 12:32 09.04.2002, Pierre-Alain Joye wrote:
Would it be so bad allowing closed source?
I really do not care, but I really appreciate and use only ( for my dev )
open sources products, but that is not the question, and was a joke == ;)
:))
I think having one of MI, aggregation and interfaces is essential for OO
modelling.
I m not a professionnal of OO design, but do not see how interfaces in php
will help us during the design phases.
Where do you use interfaces during the modelling phase ? If you use pear::db
and an interface is available, how do you will use it ? ( no irony in these
questions, just interested).
pa
Lets A be a generic interface to do some work. Then A is an abstract object.
Lets B be a specific implementation on some other stuff. And let assume that
B has to be used for the same work as A was designed for.
Then we could have C be totally different from B but able to take its place
according to A.
Ok. Example:
class Collection is a class that allows collection o objects.
class A and class B are some classes.
Now Collection must store objects in general and it is not able to
communicate with the objects it stores.
Now implementing sorted lists:
Instance Item is an interface that allows comparison of to Items in
Collection by a method.
interface Item {
function ItemContent() { ... }
}
class Collection {
...
function Sort() {
...
$diff = $a-ItemContent() - $b-ItemContent();
...
}
function Insert($o) {
if ( !$o is Item) {
echo Error: O is not Item;
} else {
insert
}
}
}
class A implements Item {
var $a;
function ItemContent() {
return $this-a;
}
}
class B implements Item {
var $b;
function ItemContent() {
return $this-b;
}
}
helped?
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
hi all, I'm personally in favour of having MI in PHP, with the serious alternative being interfaces. I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. 1) the whole concept of interfaces as they are in Java can be thought of as a *subset* of the functionality of MI (when combined with abstract classes), and that being said, it is obvious that everything that can be done with interfaces, can also be done with MI by inheriting from abstract classes (as you would in C++). but with MI you can do even more - you can multiply inherit implementation. so, why cut off possibilities? i agree with Zeev here, MI is definitely superior to interfaces. 2) interfaces lose their meaning in a loosely-typed language such as PHP, which is so dynamic that no attribute nor method declarations are required in order to write code around an object. interfaces are nothing but abstract classes, which do not allow implementation or instantiation. but you do not even have abstract classes in PHP - the compiler doesn't prevent you from trying to call a method that isn't there... the error pops up as late as at runtime. in PHP, object interfaces only exist in the heads of the programmers, not in the compiler, they just aren't there. this way, it doesn't matter if programmers draw interfaces on sand using UML in order to communicate with each other, PHP compiler does not need to know about interfaces. therefore, interfaces really do sound kind of silly in the context of the PHP language. regards, lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
At 15:26 09.04.2002, Lauri Liinat wrote: hi all, I'm personally in favour of having MI in PHP, with the serious alternative being interfaces. I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. 1) the whole concept of interfaces as they are in Java can be thought of as a *subset* of the functionality of MI (when combined with abstract classes), and that being said, it is obvious that everything that can be done with interfaces, can also be done with MI by inheriting from abstract classes (as you would in C++). but with MI you can do even more - you can multiply inherit implementation. so, why cut off possibilities? i agree with Zeev here, MI is definitely superior to interfaces. 2) interfaces lose their meaning in a loosely-typed language such as PHP, which is so dynamic that no attribute nor method declarations are required in order to write code around an object. interfaces are nothing but abstract classes, which do not allow implementation or instantiation. but you do not even have abstract classes in PHP - the compiler doesn't prevent you from trying to call a method that isn't there... the error pops up as late as at runtime. in PHP, object interfaces only exist in the heads of the programmers, not in the compiler, they just aren't there. this way, it doesn't matter if programmers draw interfaces on sand using UML in order to communicate with each other, PHP compiler does not need to know about interfaces. therefore, interfaces really do sound kind of silly in the context of the PHP language. regards, lauri totally correct. but some people here like me want to have some control in the engine that allows detection of missuse of class modells. That is i supply a class package and the user says hey your package does not work and i say hey you missused the package and can present him with the errorlog. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Lauri Liinat [EMAIL PROTECTED] wrote:
hi all,
I'm personally in favour of having MI in PHP, with the serious alternative
being interfaces. I have failed to understand what interfaces would mean
in a language such as PHP, though, while I can see the clear hands-on use
for MI.
1) the whole concept of interfaces as they are in Java can be thought of
as a *subset* of the functionality of MI (when combined with abstract
classes), and that being said, it is obvious that everything that can
be done with interfaces, can also be done with MI by inheriting
from abstract classes (as you would in C++). but with MI you can do
even more - you can multiply inherit implementation. so, why cut off
possibilities? i agree with Zeev here, MI is definitely superior to
interfaces.
2) interfaces lose their meaning in a loosely-typed language such as PHP,
which is so dynamic that no attribute nor method declarations are
required in order to write code around an object. interfaces are nothing but
abstract classes, which do not allow implementation or instantiation.
but you do not even have abstract classes in PHP - the compiler doesn't
prevent you from trying to call a method that isn't there... the error pops
up
as late as at runtime. in PHP, object interfaces only exist in the heads of
the
programmers, not in the compiler, they just aren't there. this way, it
doesn't
matter if programmers draw interfaces on sand using UML in order to
communicate with each other, PHP compiler does not need to know about
interfaces. therefore, interfaces really do sound kind of silly in the
context
of the PHP language.
Im also a -1 on interfaces. They don't fit into php nicely. Besides interfaces
don't let you include implemntation.
Ok... so where do we go with this thread.
a vote?
plain ole MI..
class a extends b,foo,bar;
or a new keyword aggregates...
class a extends b aggregates foo, bar;
The first is less confusing but doesn't really make sence as far as describing
the relationship OO.
The second is more confusing but really describes the relationship between the
objects.
here are some examples...
class serializable
{
function serialize()
{
return implode(:, $this);
}
}
class stack aggregates serializable;
$stack = new stack();
echo $stack-seralize();
...
class mythread extends thread aggregates runnable;
...
- 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
Re: [PHP-DEV] Re: aggergate vs MI
On Tue, 2002-04-09 at 16:47, brad lafountain wrote:
--- Lauri Liinat [EMAIL PROTECTED] wrote:
hi all,
I'm personally in favour of having MI in PHP, with the serious alternative
being interfaces. I have failed to understand what interfaces would mean
in a language such as PHP, though, while I can see the clear hands-on use
for MI.
1) the whole concept of interfaces as they are in Java can be thought of
as a *subset* of the functionality of MI (when combined with abstract
classes), and that being said, it is obvious that everything that can
be done with interfaces, can also be done with MI by inheriting
from abstract classes (as you would in C++). but with MI you can do
even more - you can multiply inherit implementation. so, why cut off
possibilities? i agree with Zeev here, MI is definitely superior to
interfaces.
2) interfaces lose their meaning in a loosely-typed language such as PHP,
which is so dynamic that no attribute nor method declarations are
required in order to write code around an object. interfaces are nothing but
abstract classes, which do not allow implementation or instantiation.
but you do not even have abstract classes in PHP - the compiler doesn't
prevent you from trying to call a method that isn't there... the error pops
up
as late as at runtime. in PHP, object interfaces only exist in the heads of
the
programmers, not in the compiler, they just aren't there. this way, it
doesn't
matter if programmers draw interfaces on sand using UML in order to
communicate with each other, PHP compiler does not need to know about
interfaces. therefore, interfaces really do sound kind of silly in the
context
of the PHP language.
Im also a -1 on interfaces. They don't fit into php nicely. Besides interfaces
don't let you include implemntation.
Ok... so where do we go with this thread.
a vote?
plain ole MI..
class a extends b,foo,bar;
or a new keyword aggregates...
class a extends b aggregates foo, bar;
The first is less confusing but doesn't really make sence as far as describing
the relationship OO.
The second is more confusing but really describes the relationship between the
objects.
here are some examples...
class serializable
{
function serialize()
{
return implode(:, $this);
}
}
class stack aggregates serializable;
$stack = new stack();
echo $stack-seralize();
...
class mythread extends thread aggregates runnable;
...
Please note that _real_ aggregation has an _instance_ of the aggregated
class in the object you apply the aggregate to. The current PHP
implementation shortcuts this though, and is in effect runtime multiple
inheritance.
Andrei did put a lot of work into the current implementation, and it is
faster than the real thing.
I think an aggregates statement during class definition like you
suggest above could work.
I don't think interfaces have anything to do in PHP due to its
loosely-typed and runtime-dynamic nature.
If PHP does get a form of MI, it should share implementation with
aggregate, to avoid tiny but annoying semantical differences. :-)
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: aggergate vs MI
At 13:12 09/04/2002, Pierre-Alain Joye wrote: I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? The only needs of interfaces I see is only for php encoded and closed source (we can called them binaries ;) ). And in this case, I do not like it ;). It doesn't effect them either. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
At 14:03 09/04/2002, Wez Furlong wrote: On 09/04/02, Zeev Suraski [EMAIL PROTECTED] wrote: COM's a hack, though. It really is. What they did in ATL basically does a fair amount of magic to give you the ability to inherit code with COM's strict binary compatible model... COM implemented in C/C++ is, as you say, a hack. It was born there, after Microsoft figured out that dynamic libraries were really hellish :) When the language supports COM style interfaces natively, it starts looking less like a hack and more like something really nice. Well, I guess it's a matter of perspective, but I think that it's no coincidence they moved away from COM :) There is another point that keeps coming to mind when comparing MI with interfaces: method name conflicts. Consider this, using an MI approach to implementing interfaces: [snip] Hmm, you refer to interfaces a-la COM? Hmm, I was under the impression that if we use interfaces, it'll be the same as Java, and then what you said about naming conflicts doesn't apply at all. QueryInterface() is a hack, which may have a positive side effect (avoids naming collisions), but it's still a hack :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
You described my thoughts *perfectly* - thanks :) Zeev At 16:26 09/04/2002, Lauri Liinat wrote: hi all, I'm personally in favour of having MI in PHP, with the serious alternative being interfaces. I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. 1) the whole concept of interfaces as they are in Java can be thought of as a *subset* of the functionality of MI (when combined with abstract classes), and that being said, it is obvious that everything that can be done with interfaces, can also be done with MI by inheriting from abstract classes (as you would in C++). but with MI you can do even more - you can multiply inherit implementation. so, why cut off possibilities? i agree with Zeev here, MI is definitely superior to interfaces. 2) interfaces lose their meaning in a loosely-typed language such as PHP, which is so dynamic that no attribute nor method declarations are required in order to write code around an object. interfaces are nothing but abstract classes, which do not allow implementation or instantiation. but you do not even have abstract classes in PHP - the compiler doesn't prevent you from trying to call a method that isn't there... the error pops up as late as at runtime. in PHP, object interfaces only exist in the heads of the programmers, not in the compiler, they just aren't there. this way, it doesn't matter if programmers draw interfaces on sand using UML in order to communicate with each other, PHP compiler does not need to know about interfaces. therefore, interfaces really do sound kind of silly in the context of the PHP language. regards, lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
I totally agree with point 2). However on point 1, MI allows you to inherit from non-abstract classes, which causes problems (I will send an email later tonight about those problems, my laptop crashed when I sent it this morning). If there was enforcement for allowing only abstract classes to be multiply inherited (which admitelly would start being hell from programmers), then it would look like interfaces (which are supposedly more understandable by programmers..uhuh). Point 2, however would prohibit this enforcement, so we're back to square one. I like aggregation because it kind of forces programmers to modularize components of classes. When MI is used, we often see a mix of functions that reference many classes inside the class that extended the other classes (are you confused yet?). Aggregation, however, is kinda hard to read by people that don't really understand object oriented programming and just refer to classes as a language convenience but don't go beyond it and really use classes as they should be, extendable objects or reusable objects (and not both at the same time). I like clean code, and I think aggregation would be cleaner, but it could be a burden, and we want people to use php. Tough decisions :) Fab. From: Zeev Suraski [EMAIL PROTECTED] To: Lauri Liinat [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: aggergate vs MI Date: Tue, 09 Apr 2002 19:25:18 +0300 You described my thoughts *perfectly* - thanks :) Zeev At 16:26 09/04/2002, Lauri Liinat wrote: hi all, I'm personally in favour of having MI in PHP, with the serious alternative being interfaces. I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. 1) the whole concept of interfaces as they are in Java can be thought of as a *subset* of the functionality of MI (when combined with abstract classes), and that being said, it is obvious that everything that can be done with interfaces, can also be done with MI by inheriting from abstract classes (as you would in C++). but with MI you can do even more - you can multiply inherit implementation. so, why cut off possibilities? i agree with Zeev here, MI is definitely superior to interfaces. 2) interfaces lose their meaning in a loosely-typed language such as PHP, which is so dynamic that no attribute nor method declarations are required in order to write code around an object. interfaces are nothing but abstract classes, which do not allow implementation or instantiation. but you do not even have abstract classes in PHP - the compiler doesn't prevent you from trying to call a method that isn't there... the error pops up as late as at runtime. in PHP, object interfaces only exist in the heads of the programmers, not in the compiler, they just aren't there. this way, it doesn't matter if programmers draw interfaces on sand using UML in order to communicate with each other, PHP compiler does not need to know about interfaces. therefore, interfaces really do sound kind of silly in the context of the PHP language. regards, lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
I'm personally in favour of having MI in PHP, with the serious alternative being interfaces. I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? Zeev Ohh! The first thing I would do with an interface capability is use it to dynamicly generate WSDL :) The ability to do that would make me very happy. I was thinking I would just write up an IDL parser to do this, but if it's built into the language, all the better! Hmm, would an interface system in PHP allow for defining data types/structures on parameters? Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
At 20:30 09.04.2002, you wrote: I'm personally in favour of having MI in PHP, with the serious alternative being interfaces. I have failed to understand what interfaces would mean in a language such as PHP, though, while I can see the clear hands-on use for MI. Can you explain how you envision interfaces as useful constructs in PHP, and their advantages over MI, considering the fact all of the binary compatibility issues don't apply? Zeev Ohh! The first thing I would do with an interface capability is use it to dynamicly generate WSDL :) The ability to do that would make me very happy. I was thinking I would just write up an IDL parser to do this, but if it's built into the language, all the better! Hmm, would an interface system in PHP allow for defining data types/structures on parameters? Shane If types/structs are allowed for parameters then we would need a type-system. That we don't have yet. the only types we have are strings, arrays and numbers (and boolean). And anything can be converted implicitly. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
On Mon, 2002-04-08 at 02:50, brad lafountain wrote: --- Stig S. Bakken [EMAIL PROTECTED] wrote: On Sun, 2002-04-07 at 20:35, brad lafountain wrote: What would be wrong with having the *_SQL_* objects be a member of the *_Connection* classes? What you're describing here is object aggregation. What do you mean... Im saying that the SQL implementation is a member or the connection class.. Nothing to do with aggergation. aggergation would mean the methods of the sql imp would be apart of the connection class not a member. Im still not convinced that aggergation is usefull. Object aggregation in general is a technique where you have some functionality in objects you forward calls to, a pretty common technique. You can of course do that in PHP today, but it's slow (lots of userland method calls) and high on maintenance (if an aggregated class gets a new method, you must make a new wrapper in the forwarding class, etc). In my opinion, providing native support for this in an efficient way makes a lot of sense for PHP. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
brad lafountain wrote: Unless someone could give me a real reason that aggerate is better than MI. Aggregation does at runtime what MI does at compile time. Delaying the decision to do something is usually an enable for specific applications. Examples are the signal/slot mechanism based call-models in Gnome and Qt vs. virtual function tables in C++. The decision which implementation for a method is being called is delayed to the actual point in time when a call is being made, enabling a much more flexible component model and much better reuse. The cost for doing things late is worse typechecking, errors are potentially caught only at call-time, not at compile-time (with Qt, it probably is link-time, due to the way it is implemented). The same goes with aggregation. Aggregation allows me to write a class Soaping, which implements a SOAP RPC Client and a SOAPFactory class, which manufactures objects of any class and aggregates Soaping into them: I could include_once() any unknown class, create an instance and use PHPs introspective functions to create a list of functions and instance variables in this class. By adding Soaping functionality to the class, and with the help of getters, setters and wrappers provided by overload(), I can intercept all accesses to this instance, turn them into SOAP calls to some remote instance of that object, and marshall the results back into my application. The beauty of this is, that I can do this at run-time, and that I can do this generically with any old class, using two miniscule additions to the system, aggregate() and overload(). Yet for the user this is probably transparent. Class definition is defined at design time not run time! No, it isn't. Unless you are stuck with C++. PHP is for rapid prototyping. That may turn into rabid prototyping (SCNR the pun) if you do not know how to use it, but it may also be an extremely powerful tool as I have shown. Generally speaking, it allows you to design metaclasses and metasystems, which add some general function to the language itself. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
Stig S. Bakken wrote: Example set of classes using aggregate to customize at runtime: DB_Connection generic connection object DB_Connection_odbc layer interfacing to PHP's odbc functions DB_Connection_oracle ditto for Oracle DB_Connection_mysqlditto for MySQL DB_SQL_oracle SQL portability layer for Oracle DB_SQL_mysql ditto for MySQL If the user requests a connection to an Oracle database, the connect function returns an instance of DB_Connection that has aggregated DB_Connection_oracle and DB_SQL_oracle. But if the user requests a connection to Oracle through ODBC, the connect function returns an instance of DB_Connection that has aggregated DB_Connection_odbc. After connecting to the database, DB_Connection_odbc detects that it is used against Oracle and aggregates DB_SQL_oracle. You can do all this almost the same way you have shown using MI and a factory object. You would premix your classes to get a static (determined at compile time) mix, and have the factory return the appropriately mixed class. That's why I was using a generic RPC proxy and a Soaping mixin in my example. In my example the actual classes being mixed are not fixed, and are in fact not known until include_once() time (runtime). Aggegration allows you to mix functionality into existing classes dynamically, include_once() allows you to load code dynamically. Thus, any attempt to solve this at compiletime is doomed. Generally speaking it is about class and type. A type describes what an object can do, it's signature. The signature is a canonic serialization of all its instance variable names and function signatures. A class is where the object got these instance variables and functions from. In languages where class == type, functionality is either inherited or locally defined. But there are languages where functionality is not restricted to these sources but may be provided in other ways. Aggregation is one way to get functionality besides inheriance, and makes PHP a language where class != type, if desired. Traditionally, PHP always was class != type when it came to instance variables. $this-$b was a valid construct for any $b containing a valid variable name (and many invalid ones as well). Traditionally PHP also was limited in how it could aquire functions in objects, so it was class == type for functions of an object. Aggregate fixed that by providing the missing API. Stig's first attempt at aggregate() broke serialization and thus sessions, because serialze() assumes that is enough to note the class of an object in order to describe its type. That assumption had always been false, but there was no API to break it. For instance variables, serialize() always recorded the type, but for methods it recorded the class as a reasonable shortcut. In fact we could keep Stig's first version of aggregate(), if serialize() recorded the type of an object for its methods, too. It would have to write a log that describes how the object aquired its functionality in order to recreate that upon deserialization() (in PHPLIB terms, change $o = new Class; # aggregate($o, anotherClass); $o-slot = 17; so that the aggregate statement is recorded and generated in the session data) It is only because of the uglyness of this approach that Stig revised his implementation of aggregate() so that it does not break the (actually false) assumption of serialize() that class == type for methods. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
Kristian Köhntopp wrote: brad lafountain wrote: Unless someone could give me a real reason that aggerate is better than MI. Aggregation does at runtime what MI does at compile time. Delaying the decision to do something is usually an enable for specific applications. I agree. It would be useful some application. Brad, Having aggregate will affects MI support at script engine level? If it affects or may affect, we are better to make it a experimental at least. We don't have to limit ourself at this point, right? -- Yasuo Ohgaki Examples are the signal/slot mechanism based call-models in Gnome and Qt vs. virtual function tables in C++. The decision which implementation for a method is being called is delayed to the actual point in time when a call is being made, enabling a much more flexible component model and much better reuse. The cost for doing things late is worse typechecking, errors are potentially caught only at call-time, not at compile-time (with Qt, it probably is link-time, due to the way it is implemented). The same goes with aggregation. Aggregation allows me to write a class Soaping, which implements a SOAP RPC Client and a SOAPFactory class, which manufactures objects of any class and aggregates Soaping into them: I could include_once() any unknown class, create an instance and use PHPs introspective functions to create a list of functions and instance variables in this class. By adding Soaping functionality to the class, and with the help of getters, setters and wrappers provided by overload(), I can intercept all accesses to this instance, turn them into SOAP calls to some remote instance of that object, and marshall the results back into my application. The beauty of this is, that I can do this at run-time, and that I can do this generically with any old class, using two miniscule additions to the system, aggregate() and overload(). Yet for the user this is probably transparent. Class definition is defined at design time not run time! No, it isn't. Unless you are stuck with C++. PHP is for rapid prototyping. That may turn into rabid prototyping (SCNR the pun) if you do not know how to use it, but it may also be an extremely powerful tool as I have shown. Generally speaking, it allows you to design metaclasses and metasystems, which add some general function to the language itself. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Kristian Köhntopp [EMAIL PROTECTED] wrote: brad lafountain wrote: Unless someone could give me a real reason that aggerate is better than MI. Aggregation does at runtime what MI does at compile time. Delaying the decision to do something is usually an enable for specific applications. Examples are the signal/slot mechanism based call-models in Gnome and Qt vs. virtual function tables in C++. The decision which implementation for a method is being called is delayed to the actual point in time when a call is being made, enabling a much more flexible component model and much better reuse. Im not familure with this can you please explain. The cost for doing things late is worse typechecking, errors are potentially caught only at call-time, not at compile-time (with Qt, it probably is link-time, due to the way it is implemented). The same goes with aggregation. Aggregation allows me to write a class Soaping, which implements a SOAP RPC Client and a SOAPFactory class, which manufactures objects of any class and aggregates Soaping into them: I could include_once() any unknown class, create an instance and use PHPs introspective functions to create a list of functions and instance variables in this class. By adding Soaping functionality to the class, and with the help of getters, setters and wrappers provided by overload(), I can intercept all accesses to this instance, turn them into SOAP calls to some remote instance of that object, and marshall the results back into my application. The beauty of this is, that I can do this at run-time, and that I can do this generically with any old class, using two miniscule additions to the system, aggregate() and overload(). Yet for the user this is probably transparent. I have made this exact soap client and server as a php extension. It works fine without aggregation. Class definition is defined at design time not run time! No, it isn't. Unless you are stuck with C++. PHP is for rapid prototyping. That may turn into rabid prototyping (SCNR the pun) if you do not know how to use it, but it may also be an extremely powerful tool as I have shown. Generally speaking, it allows you to design metaclasses and metasystems, which add some general function to the language itself. I guess my biggest argument is that aggergration will cause some problems like serizliation and Im still not convinced that aggergration does any good when you are designing a class libary. Basically I don't want aggergation to be the only way that a user can have MI just because MI isn't implemented. I can see users doing this. class A; class B; class C; $c = new C; aggergate($c, A); aggergate($c, B); Just because they can. Not be cause it makes sence or its readable. I guess it would aleviate my conserns if MI was included as well as aggergation. - 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
Re: [PHP-DEV] Re: aggergate vs MI
--- Stig S. Bakken [EMAIL PROTECTED] wrote: On Mon, 2002-04-08 at 02:50, brad lafountain wrote: --- Stig S. Bakken [EMAIL PROTECTED] wrote: On Sun, 2002-04-07 at 20:35, brad lafountain wrote: What would be wrong with having the *_SQL_* objects be a member of the *_Connection* classes? What you're describing here is object aggregation. What do you mean... Im saying that the SQL implementation is a member or the connection class.. Nothing to do with aggergation. aggergation would mean the methods of the sql imp would be apart of the connection class not a member. Im still not convinced that aggergation is usefull. Object aggregation in general is a technique where you have some functionality in objects you forward calls to, a pretty common technique. You can of course do that in PHP today, but it's slow (lots of userland method calls) and high on maintenance (if an aggregated class gets a new method, you must make a new wrapper in the forwarding class, etc). In my opinion, providing native support for this in an efficient way makes a lot of sense for PHP. Ok, Im still not convinced that I personally will ever use aggregation but im sure someone out there somewhere would want to use it. But my consern is that people will start using aggregation instead of normal MI. Aggregation should only be used at certin times not just for MI. (as i said in another post) Basically I don't want aggergation to be the only way that a user can have MI just because MI isn't implemented. I can see users doing this. class A; class B; class C; $c = new C; aggergate($c, A); aggergate($c, B); Just because they can. Not be cause it makes sence or its readable. I guess it would aleviate my conserns if MI was included as well as aggergation. (as i said in another post) - 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
Re: [PHP-DEV] Re: aggergate vs MI
On Mon, Apr 08, 2002 at 08:59:39AM -0700, brad lafountain wrote: class A; class B; class C; $c = new C; aggergate($c, A); aggergate($c, B); Just because they can. Yes of course, but how is this better than class D extends A, B, C; $d = new D; for the same reasons (i.e. because you can as opposed to it makes sense???) Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Kristian Koehntopp [EMAIL PROTECTED] wrote: On Mon, Apr 08, 2002 at 08:59:39AM -0700, brad lafountain wrote: class A; class B; class C; $c = new C; aggergate($c, A); aggergate($c, B); Just because they can. Yes of course, but how is this better than class D extends A, B, C; $d = new D; for the same reasons (i.e. because you can as opposed to it makes sense???) Yeah now they can use D over and over agian with out having to aggregate it over and over again because it IS defineable at compile time. class circle; class square; class 3d_object; class 2d_object; class 3d_circle extends circle, 3d_object; class 2d_square extends square, 2d_object; class 3d_square extends square, 3d_object; $obj1 = new 3d_circle; $obj2 = new 2d_square; $obj3 = new 3d_square; that is way eaiser to read than.. class circle; class square; class 3d_object; class 2d_object; $obj1 = new circle; aggregate($obj1, 3d_object); $obj2 = new square; aggregate($obj2, 2d_object); $obj3 = new square; aggregate($obj3, 3d_object); Besides that you can re-use your 3d shapes over and over again. Im saying that aggregate can be used (not too often) but having aggregate and not MI would lead to the above code. Users using aggregate as an alternative to MI. When it makes sence to do the inheritance at compile time not run time. - Brad Kristian __ 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
Re: [PHP-DEV] Re: aggergate vs MI
Having both makes very little sense. Compile-time vs. run-time in PHP doesn't make any real difference as far as functionality goes, because the stages are linked together immediately. I don't think MI will make it into PHP, now that aggregation was introduced... At 18:59 08/04/2002, brad lafountain wrote: --- Stig S. Bakken [EMAIL PROTECTED] wrote: On Mon, 2002-04-08 at 02:50, brad lafountain wrote: --- Stig S. Bakken [EMAIL PROTECTED] wrote: On Sun, 2002-04-07 at 20:35, brad lafountain wrote: What would be wrong with having the *_SQL_* objects be a member of the *_Connection* classes? What you're describing here is object aggregation. What do you mean... Im saying that the SQL implementation is a member or the connection class.. Nothing to do with aggergation. aggergation would mean the methods of the sql imp would be apart of the connection class not a member. Im still not convinced that aggergation is usefull. Object aggregation in general is a technique where you have some functionality in objects you forward calls to, a pretty common technique. You can of course do that in PHP today, but it's slow (lots of userland method calls) and high on maintenance (if an aggregated class gets a new method, you must make a new wrapper in the forwarding class, etc). In my opinion, providing native support for this in an efficient way makes a lot of sense for PHP. Ok, Im still not convinced that I personally will ever use aggregation but im sure someone out there somewhere would want to use it. But my consern is that people will start using aggregation instead of normal MI. Aggregation should only be used at certin times not just for MI. (as i said in another post) Basically I don't want aggergation to be the only way that a user can have MI just because MI isn't implemented. I can see users doing this. class A; class B; class C; $c = new C; aggergate($c, A); aggergate($c, B); Just because they can. Not be cause it makes sence or its readable. I guess it would aleviate my conserns if MI was included as well as aggergation. (as i said in another post) - 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Zeev Suraski [EMAIL PROTECTED] wrote:
Having both makes very little sense. Compile-time vs. run-time in PHP
doesn't make any real difference as far as functionality goes, because the
stages are linked together immediately.
I don't think MI will make it into PHP, now that aggregation was
introduced...
Yes it does make sence. How much slower would the code below run, not to
mention how hard it is to read or maintain.
class a;
class b;
class c;
for($i = 0;$i 1;$i++)
{
$d = new a;
aggregate($d, b);
aggregate($d, c);
$d-method();
}
or this
class a;
class b;
class c;
class d extends a,b,c;
for($i = 0;$i 1;$i++)
{
$d = new d;
$d-method();
}
Its all about desiging your objects.. if d always consits of a,b and c then MI
should be used. If some condition arises where d is only a and b or a and c.
then aggregation should be used.
Eg.
$d = new a;
if(condition)
aggregate($d, 'b');
elseif(codition)
aggregate($d, 'c');
$d-method();
That makes sence.
But not doign this.
$d = new a;
aggregate($d, 'b');
aggregate($d, 'c');
$d-method();
I currently am trying to talk my company to use php over java. This is a huge
project. The company i work for has 22000 employees and probally 500-1000
developers across us (mainly). And in desiging our classes i can see where i
could use MI. and im not about to go and tell all 500 developers that evertime
you create an instance of x you need to aggerate y.
If aggregation is included then i see it is absoulty necessary to include MI
too.
- brad
At 18:59 08/04/2002, brad lafountain wrote:
--- Stig S. Bakken [EMAIL PROTECTED] wrote:
On Mon, 2002-04-08 at 02:50, brad lafountain wrote:
--- Stig S. Bakken [EMAIL PROTECTED] wrote:
On Sun, 2002-04-07 at 20:35, brad lafountain wrote:
What would be wrong with having the *_SQL_* objects be a member
of the
*_Connection* classes?
What you're describing here is object aggregation.
What do you mean... Im saying that the SQL implementation is a member
or
the
connection class.. Nothing to do with aggergation. aggergation would
mean
the
methods of the sql imp would be apart of the connection class not a
member.
Im still not convinced that aggergation is usefull.
Object aggregation in general is a technique where you have some
functionality in objects you forward calls to, a pretty common
technique. You can of course do that in PHP today, but it's slow (lots
of userland method calls) and high on maintenance (if an aggregated
class gets a new method, you must make a new wrapper in the forwarding
class, etc). In my opinion, providing native support for this in an
efficient way makes a lot of sense for PHP.
Ok, Im still not convinced that I personally will ever use aggregation
but im
sure someone out there somewhere would want to use it. But my consern is
that
people will start using aggregation instead of normal MI. Aggregation should
only be used at certin times not just for MI.
(as i said in another post)
Basically I don't want aggergation to be the only way that a user can
have MI
just because MI isn't implemented. I can see users doing this.
class A;
class B;
class C;
$c = new C;
aggergate($c, A);
aggergate($c, B);
Just because they can. Not be cause it makes sence or its readable. I
guess
it would aleviate my conserns if MI was included as well as aggergation.
(as i said in another post)
- 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
__
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
Re: [PHP-DEV] Re: aggergate vs MI
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
Re: [PHP-DEV] Re: aggergate vs MI
--- Zeev Suraski [EMAIL PROTECTED] 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. Well i would have totally agreed with you yesterday.. but i have convinced myself that there is use for aggregation. Me personally i would never use it. But i can see somepeople using it. But giving the user a way to MI without having MI support(aggregation) will create alot of messy code. It wont even give the user a change to write good OO code. Can you explain why you can't see room for both of them? - 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
Re: [PHP-DEV] Re: aggergate vs MI
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
Re: [PHP-DEV] Re: aggergate vs MI
--- Steve Meyers [EMAIL PROTECTED] 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? That would be the biggest hack. MI isn't that hard to implement. It probally would take a good developer less than a weeks time to do. - Brad 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 __ 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
Re: [PHP-DEV] Re: aggergate vs MI
At 00:55 09/04/2002, brad lafountain wrote: Well i would have totally agreed with you yesterday.. but i have convinced myself that there is use for aggregation. Me personally i would never use it. But i can see somepeople using it. It doesn't mean it's a good idea to add it. I used both, and yes, aggregation makes sense in some cases, but having them both in the language is like a supermarket of everything, and that's never good. But giving the user a way to MI without having MI support(aggregation) will create alot of messy code. It wont even give the user a change to write good OO code. Can you explain why you can't see room for both of them? Aggregation is typically supported in userland, in the rare cases where it's really required (through wrapper methods that relay calls to a member object). Having them both will confuse people. Even people with some OO experience won't find it trivial to decide which they should use. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
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
Re: [PHP-DEV] Re: aggergate vs MI
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? :-) - 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
Re: [PHP-DEV] Re: aggergate vs MI
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 00:55 09/04/2002, brad lafountain wrote:
Well i would have totally agreed with you yesterday.. but i have convinced
myself that there is use for aggregation. Me personally i would never use
it.
But i can see somepeople using it.
It doesn't mean it's a good idea to add it. I used both, and yes,
aggregation makes sense in some cases, but having them both in the language
is like a supermarket of everything, and that's never good.
But giving the user a way to MI without having MI support(aggregation)
will
create alot of messy code. It wont even give the user a change to write
good OO
code.
Can you explain why you can't see room for both of them?
Aggregation is typically supported in userland, in the rare cases where
it's really required (through wrapper methods that relay calls to a member
object). Having them both will confuse people. Even people with some OO
experience won't find it trivial to decide which they should use.
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.
class a
{
function blah()
{
echo in a;
}
}
class b
{
function blah()
{
echo in b;
}
}
class c
{
function blah()
{
echo in c;
}
}
class d extends a,b,c
{
function blah()
{
echo a::blah() . b::blah() . c::blah();
}
}
how do you do that with aggregation? MI really is way different than
aggregation.
I see aggregation used for adding methods to an existing class.
class a
{
function do_a()
{
}
}
class b
{
function do_b()
{
}
}
$c = new stdclass;
aggregate($c, a);
aggregate($c, b);
$c-do_a();
$c-do_b();
but i still don't like this... there are cleaner ways around that by using
members and/or MI.
- 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
Re: [PHP-DEV] Re: aggergate vs MI
--- 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. - 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
Re: [PHP-DEV] Re: aggergate vs MI
At 00:40 09.04.2002, Stig S. Bakken 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. What i meant with runtime was that aggregation allows to change the methods of an object. IMHO there is room for both aggregate and MI. We have require and include, not just include? :-) - 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
Re: [PHP-DEV] Re: aggergate vs MI
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
Re: [PHP-DEV] Re: aggergate vs MI
Brad Lafountain wrote:
*SNIP*
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.
class a
{
function blah()
{
echo in a;
}
}
class b
{
function blah()
{
echo in b;
}
}
class c
{
function blah()
{
echo in c;
}
}
class d extends a,b,c
{
function blah()
{
echo a::blah() . b::blah() . c::blah();
}
}
With MI, documentation can be generated easily using tools.
*EASIER* to maintain code.
how do you do that with aggregation? MI really is way different than
aggregation.
I see aggregation used for adding methods to an existing class.
class a
{
function do_a()
{
}
}
class b
{
function do_b()
{
}
}
$c = new stdclass;
aggregate($c, a);
aggregate($c, b);
$c-do_a();
$c-do_b();
With aggregate, auto generating documentation hard.
*HARDER* (very hard, if one use it w/o good reason) to maintain code
To me, aggregate is GOTO like feature.
It's useful for sure, Howver
_Never_ use unless there is very good reason.
Therefore, it worth to have both MI and aggregate. IMHO
--
Yasuo Ohgaki
but i still don't like this... there are cleaner ways around that by using
members and/or MI.
- 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
Re: [PHP-DEV] Re: aggergate vs MI
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:
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
Re: [PHP-DEV] Re: aggergate vs MI
On Sat, 2002-04-06 at 23:40, brad lafountain wrote: --- Stig S. Bakken [EMAIL PROTECTED] wrote: MI is compile-time, aggregate is runtime. That's a big enough reason for me. I know the difference but how does this benifit you? Class definition is defined at design time not run time! Aggregate is not really about class definition. The shortcut in the current implementation modifies the class definition, but in its basic form, aggregation is about forwarding calls, not about changing class definitions. Thus my suggestion to change aggregate as in my first reply to Kristian. Ok... Can you give me a good example that aggergate would be used over MI. That makes sence and isn't garbage code! Okay, a good example could be a database abstraction layer supporting ODBC with special handling of each database behind ODBC. For example, if you use ODBC to talk with MySQL, Oracle or Solid, you have three ways of dealing with sequences (mysql only has auto_increment fields, Oracle has real sequences, but for Solid 2.x you need to define and use a procedure to get sequence values). If you use iODBC to do all this, you won't know which one you're talking to until after connecting. Example set of classes using aggregate to customize at runtime: DB_Connection generic connection object DB_Connection_odbc layer interfacing to PHP's odbc functions DB_Connection_oracle ditto for Oracle DB_Connection_mysqlditto for MySQL DB_SQL_oracle SQL portability layer for Oracle DB_SQL_mysql ditto for MySQL If the user requests a connection to an Oracle database, the connect function returns an instance of DB_Connection that has aggregated DB_Connection_oracle and DB_SQL_oracle. But if the user requests a connection to Oracle through ODBC, the connect function returns an instance of DB_Connection that has aggregated DB_Connection_odbc. After connecting to the database, DB_Connection_odbc detects that it is used against Oracle and aggregates DB_SQL_oracle. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Stig S. Bakken [EMAIL PROTECTED] wrote:
On Sat, 2002-04-06 at 23:40, brad lafountain wrote:
--- Stig S. Bakken [EMAIL PROTECTED] wrote:
MI is compile-time, aggregate is runtime. That's a big enough reason
for me.
I know the difference but how does this benifit you?
Class definition is defined at design time not run time!
Aggregate is not really about class definition. The shortcut in the
current implementation modifies the class definition, but in its basic
form, aggregation is about forwarding calls, not about changing class
definitions. Thus my suggestion to change aggregate as in my first
reply to Kristian.
Ok... Can you give me a good example that aggergate would be used over MI.
That makes sence and isn't garbage code!
Okay, a good example could be a database abstraction layer supporting
ODBC with special handling of each database behind ODBC.
For example, if you use ODBC to talk with MySQL, Oracle or Solid, you
have three ways of dealing with sequences (mysql only has auto_increment
fields, Oracle has real sequences, but for Solid 2.x you need to define
and use a procedure to get sequence values). If you use iODBC to do all
this, you won't know which one you're talking to until after connecting.
Example set of classes using aggregate to customize at runtime:
DB_Connection generic connection object
DB_Connection_odbc layer interfacing to PHP's odbc functions
DB_Connection_oracle ditto for Oracle
DB_Connection_mysqlditto for MySQL
DB_SQL_oracle SQL portability layer for Oracle
DB_SQL_mysql ditto for MySQL
If the user requests a connection to an Oracle database, the connect
function returns an instance of DB_Connection that has aggregated
DB_Connection_oracle and DB_SQL_oracle.
But if the user requests a connection to Oracle through ODBC, the
connect function returns an instance of DB_Connection that has
aggregated DB_Connection_odbc. After connecting to the database,
DB_Connection_odbc detects that it is used against Oracle and aggregates
DB_SQL_oracle.
Are you saying the connect function aggergates the specfic connectio class and
the specfic sql class? or the Connection class connect method aggerates the sql
class?
You don't even need aggergate or MI for this.
What would be wrong with having the *_SQL_* objects be a member of the
*_Connection* classes? It makes sence that a connection you can't have a
connection without having a SQL implementation. Then you could make a generic
one for most cases. Then you could ither have a get_sql() mehtod. This would
make more sence.
class DB_Connection_Factory
{
function get_connection($type)
{
switch($type)
{
case 'oracle':
return new DB_Connection_oracle($type);
break;
case 'odbc':
return new DB_Connection_odbc($type);
break;
...
}
}
}
class DB_Connection
{
var $sql;
function DB_Connection($type)
{
switch($type)
{
case 'oracle':
$this-sql = new DB_SQL_oracle();
break;
case 'mysql':
$this-sql = new DB_SQL_mysql();
break;
default:
$this-sql = new DB_SQL();
break;
}
}
function connect($server, $u, $p)
{
}
function set_sql($sql)
{
$this-sql = $sql;
}
}
class DB_Connection_odbc extends DB_Connection
class DB_Connection_oracle extends DB_Connection
class DB_Connection_mysql extends DB_Connection
class DB_SQL
class DB_SQL_oracle extends DB_SQL
class DB_SQL_mysql extends DB_SQL
$connection = DB_Connection_Factory::get_connection(oracle);
$connection-connect(server, l, p);
$sql = $connection-get_sql_handler();
$ret = $sql-query($query);
or
$connection = new DB_Connection();
$ret = $conection-sql-query($query);
They way that you describe first will be slower than the above code and they
way it hides the sql class from the connection class theres now way to mix and
match sql classes with connection class.
$connect-set_sql(new DB_SQL_mysql());
this works way nicer cause theres no way to unaggergate classes methods.
IMHO as far as pure OO design goes this way is way bettter than the way that
you described.
__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
Re: [PHP-DEV] Re: aggergate vs MI
On Sun, 2002-04-07 at 20:35, brad lafountain wrote: What would be wrong with having the *_SQL_* objects be a member of the *_Connection* classes? What you're describing here is object aggregation. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Stig S. Bakken [EMAIL PROTECTED] wrote: On Sun, 2002-04-07 at 20:35, brad lafountain wrote: What would be wrong with having the *_SQL_* objects be a member of the *_Connection* classes? What you're describing here is object aggregation. What do you mean... Im saying that the SQL implementation is a member or the connection class.. Nothing to do with aggergation. aggergation would mean the methods of the sql imp would be apart of the connection class not a member. Im still not convinced that aggergation is usefull. - 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
Re: [PHP-DEV] Re: aggergate vs MI
--- Yasuo Ohgaki [EMAIL PROTECTED] wrote: Brad Lafountain wrote: I keep on hearing that we are totally against MI but we want the aggergate function. Can someone PLEASE explain the reasoning behind such a decision? I can't think of one example when aggergate would be better than using MI. Aggreation works now. Multiple inheritance needs changes in ZendEngine. I am more than willing and capable to make such changes. BTW, some user asked multiple inheritance feature to php-dev, I replyed Multiple inheritance is useful, but it makes a lot easier to design objects badly. I think we are better to design objects so that multiple inheritance is not needed This is somewhat true, but how does aggerate fix this? Then I got reply, multiple inheritance is needed, etc, etc, but nobody support my idea. Therefore, most of developers like multiple inheritance, I suppose. I like MI way more than i like aggerate I honistly think, as far as OO is conserned, aggergate is garbage.. imagine reading someone elses code... trying to figure out what objects do what... and you come opon line 150 where aggerate($circle, Square);.. seriously.. IMHO this is garbage! Unless someone could give me a real reason that aggerate is better than MI. I would consider aggerate a HUGE downfall of php! Class definition is defined at design time not run time! /* brad */ -- Yasuo Ohgaki -- 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
Re: [PHP-DEV] Re: aggergate vs MI
On Sat, 2002-04-06 at 11:21, brad lafountain wrote: --- Yasuo Ohgaki [EMAIL PROTECTED] wrote: Brad Lafountain wrote: I keep on hearing that we are totally against MI but we want the aggergate function. Can someone PLEASE explain the reasoning behind such a decision? I can't think of one example when aggergate would be better than using MI. Aggreation works now. Multiple inheritance needs changes in ZendEngine. I am more than willing and capable to make such changes. BTW, some user asked multiple inheritance feature to php-dev, I replyed Multiple inheritance is useful, but it makes a lot easier to design objects badly. I think we are better to design objects so that multiple inheritance is not needed This is somewhat true, but how does aggerate fix this? Then I got reply, multiple inheritance is needed, etc, etc, but nobody support my idea. Therefore, most of developers like multiple inheritance, I suppose. I like MI way more than i like aggerate I honistly think, as far as OO is conserned, aggergate is garbage.. imagine reading someone elses code... trying to figure out what objects do what... and you come opon line 150 where aggerate($circle, Square);.. seriously.. IMHO this is garbage! So? What if the object is overloaded? What if it's some proxy class and you don't even have _access_ to the code of the methods it would call? If people want to design shitty code, they will be able to with or without aggregate. Unless someone could give me a real reason that aggerate is better than MI. I would consider aggerate a HUGE downfall of php! MI is compile-time, aggregate is runtime. That's a big enough reason for me. Class definition is defined at design time not run time! Aggregate is not really about class definition. The shortcut in the current implementation modifies the class definition, but in its basic form, aggregation is about forwarding calls, not about changing class definitions. Thus my suggestion to change aggregate as in my first reply to Kristian. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
--- Stig S. Bakken [EMAIL PROTECTED] wrote: On Sat, 2002-04-06 at 11:21, brad lafountain wrote: --- Yasuo Ohgaki [EMAIL PROTECTED] wrote: Brad Lafountain wrote: I keep on hearing that we are totally against MI but we want the aggergate function. Can someone PLEASE explain the reasoning behind such a decision? I can't think of one example when aggergate would be better than using MI. Aggreation works now. Multiple inheritance needs changes in ZendEngine. I am more than willing and capable to make such changes. BTW, some user asked multiple inheritance feature to php-dev, I replyed Multiple inheritance is useful, but it makes a lot easier to design objects badly. I think we are better to design objects so that multiple inheritance is not needed This is somewhat true, but how does aggerate fix this? Then I got reply, multiple inheritance is needed, etc, etc, but nobody support my idea. Therefore, most of developers like multiple inheritance, I suppose. I like MI way more than i like aggerate I honistly think, as far as OO is conserned, aggergate is garbage.. imagine reading someone elses code... trying to figure out what objects do what... and you come opon line 150 where aggerate($circle, Square);.. seriously.. IMHO this is garbage! So? What if the object is overloaded? What if it's some proxy class and you don't even have _access_ to the code of the methods it would call? If people want to design shitty code, they will be able to with or without aggregate. Unless someone could give me a real reason that aggerate is better than MI. I would consider aggerate a HUGE downfall of php! MI is compile-time, aggregate is runtime. That's a big enough reason for me. I know the difference but how does this benifit you? Class definition is defined at design time not run time! Aggregate is not really about class definition. The shortcut in the current implementation modifies the class definition, but in its basic form, aggregation is about forwarding calls, not about changing class definitions. Thus my suggestion to change aggregate as in my first reply to Kristian. Ok... Can you give me a good example that aggergate would be used over MI. That makes sence and isn't garbage code! --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
