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.
