--- 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
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,
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
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
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
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
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
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,
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
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
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
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
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
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
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
--- 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.
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
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,
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
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,
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
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
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
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
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
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
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
--- 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
--- 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
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
--- 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
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
--- 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
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
--- 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
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.
--- 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
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
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
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,
--- 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
--- 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
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
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
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()
{
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...
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
--- 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?
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:
--- 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
--- 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
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
--- 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
53 matches
Mail list logo
