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.
>>
>>Best regards,
>> Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
