Andi Gutmans wrote:
Well $proxy would automagically support the interfaces of the aggregated objects. And if there's a method you want to proxy to one rather the other you could fine tune that. Anything more than that would be getting into an OOP pissing contest which I don't feel like getting into, as it would be academic and wouldn't be suitable for the PHP audience...
in a totally non-academic and impure way I have always thought that it would
be nice to be able to define function bodies in interface declarations
... I realise that every computer science major is now screaming 'no' but
from a practical phper's POV it seems efficient to be able to say:
interface Printable {
function print() {
// do simple generic stuff here
// maybe go wild with some reflection :-)
}
}
I would see this as a optional addition to the syntax of interfaces...
i.e. everything works as before but you can add default function bodies
which would behave as if it was defined in each class that implements
the given interface.
IMHO interfaces would be a stronger tool because of the increased code reuse,
I find interfaces a very nice addition but I'm sometimes miffed at the need
to redefine an identical function X times (in situations where there are already
class hierarchies that do not lend themselves to incorporating the 'interface'
implementation in some base class).
if this is a truely evil concept I would very much appreciate a little
heads up as to why :-)
rgds,
Jochem
ps. and again (hey I'm a broken record too!) thanks for php!
Pretty Happy Punter.
Andi
At 03:43 PM 8/24/2005, Marcus Boerger wrote:
Hello Andi,
hu?
Here's you example again:
<?php
$proxy = new Proxy()
$proxy->aggregate($obj2); /* Also aggregates interfaces */
$proxy->aggregate($obj3);
$proxy->delegate($obj3, "method_that_exists_in_both_objects");
?>
ok lets change this to an interface like in my example:
<?php
interface Printable { function print(); }
class Document extends Proxy implements Printable
{
// now you need to implement the functions of Printable, only how?
// implement them as empty and later overload them with their real body?
}
?>
So what do you want to do about the fact that my delegates are done at
compile time while your aggregation is run at compile time? And no,
at the moment there is absolutley no way than to completley rewrite the
object/interface stuff in php to allow dynamic interfaces which your
proposal would need become compatible. And even if you did you'd simply
overthrow the idea of interfaces, wouldn't you?
best regards
marcus
Thursday, August 25, 2005, 12:35:11 AM, you wrote:
Not if it's done they way I think it can be done...
At 03:17 PM 8/24/2005, Marcus Boerger wrote:
Hello Andi,
you mean fine tune the 'protocol' to use the correct wording. It
simply is
incompatible with the interface concept.
Wednesday, August 24, 2005, 11:48:33 PM, you wrote:
I don't mind not adding it, as long as we don't add "delegate" :)
Anyway, it's different from MI because it allows you to fine tune the
interface...
Andi
At 12:01 PM 8/24/2005, Marcus Boerger wrote:
Hello Andi,
i said 'we could probably add'. But even though
proxy/aggregation idea
like you offered and which i of course could implement in spl
exists i
still see no reason for it. The problem with the latter is that
it only
gives you back the original MI problems and doesn't work together
with
interfaces at all. Thus i see it as contraproductive. Or in other
words
let's simply not add something here and live with code reuse.
Unless it
turns out in the future that it becomes the normal thing - by
that time we
might have PHP 8 wishlist ;-)
regards
marcus
Wednesday, August 24, 2005, 1:27:20 AM, you wrote:
Again (I sound like a broken record), I don't think that we
should
add language constructs to support delegation. We will be
overcomplicating things for PHP developers and it'll start to
be hard
to read PHP code.
I do think it might be worth considering a user-land or internal
class such as a Proxy class which would allow the advanced
user to
have more find-grained control on delegation.
I'd still keep it simple. So basically I'd allow aggregating
objects
(or delegatees), and define their priority in the order they are
added. Then there could be one method which overrides this
priority
by allowing to map methods to objects. For example something
like:
$proxy = new Proxy()
$proxy->aggregate($obj2); /* Also aggregates interfaces */
$proxy->aggregate($obj3);
$proxy->delegate($obj3, "method_that_exists_in_both_objects");
This would only be used in very advanced cases, most probably in
frameworks but would be invisible to the average PHP developer.
Complicating it more than this including the addition of language
constructs doesn't seem good to me. If this isn't enough (and I"m
sure there are some hypothetical cases where it might not be),
then
you could achieve the same goal in other ways...
Still I am torn wether even this should be added.
Andi
At 12:57 PM 8/23/2005, Marcus Boerger wrote:
Hello Zeev,
Tuesday, August 23, 2005, 8:59:49 PM, you wrote:
At 19:12 23/08/2005, Lukas Smith wrote:
Joseph Crawford wrote:
I would like to see Multiple Inheritance implemented in a
future version.
I am not sure what obstacles got in the way (if any) for not
implementing
that in PHP 5 but i would defenately like to see that in
PHP 6 or 7
IIRC, it was shot down. Use overloading and interfaces to get
similar effects.
You're right, it was, that's why we have interfaces.
Exactly. And you can emulate MI with __call().
The only thing we could probably add is delegates to overcome the
anti-code-reuse interface aspect.
// Some interface
interface Printable {
function print();
}
// A general implementation for the interface
class PrintHandler implements Printable {
function print() { /* ... */ }
}
// A standard user class that implements the interface. Typically
this is the
// reason for MI since often you would just go with a standard
impl for the
// interfaced code. Actually common with containers (*).
class Document implements Printable {
delegate Printable $print;
function __construct() {
$this->print = new PrintHandler($this);
}
// No need to provide function print here - actually doing so
is an error
// since tit's body is automatically generated as a call to
the delegate:
// function print() {
// if (!$this->print) throw new Exception("Delegate must not
be NULL");
// $this->print->print();
// }
}
On the one hand this raises the complexity and syntax magic.
On the other
way it is really elegant and promotes code-reuse which is
otherwise a pain
with interfaces.
(*) Actually the most prominent case is a general Container and a
base class
in a GUI Framwork. There the desktop and the windows need
containers too. So
you'd habe an interface to access the container and implement
it againa and
again...even though you already have it. And if you find a
mistake - nobody
tells you whether you fixed all incarnations of the code.