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
