Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41955
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain rwth-aachen.de from 134.130.7.73 cause and error)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=ISO-8859-1
Message-ID: <49211FED.3020302@rwth-aachen.de>
Date: Mon, 17 Nov 2008 08:40:29 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7)
 Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666
To: php@stefan-marr.de
Cc: internals@lists.php.net
References: <002b01c92d67$ae92fdc0$0bb8f940$@de>
 <79.C8.07308.CDE4C194@pb1.pair.com> <49203DF2.1020006@stefan-marr.de>
In-reply-to: <49203DF2.1020006@stefan-marr.de>
OpenPGP:
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: christopher.vogt@rwth-aachen.de (Christopher Vogt)

Hej,

>> I really liked to see the Grafts proposal.
> Well, I'm still in love with the more powerful (because they are
> interweaveable(breakable)) Traits ;)

I don't think there has to be a choice between Grafts and Traits. They
serve different purposes and I don't see a reason they shouldn't
co-exit. Traits implement code reuse. Code is merged. This is very
powerful but can break code. Grafts implement delegation. This is less
powerful, but can't break, which makes it preferable, whenever possible.

> Actually I think this could be a problem for the conciseness of the
> language. Introducing syntactic sugar for special situations has to be
> done carefully.

In my eyes (well-chosen) syntactic sugar contributes a lot to language
conciseness. And every language decision should be done carefully, right?

> from my perspective forwarding (aka
> delegation) is a very common concept in OOP which would be worth to be
> supported by a special syntax.

I strongly think so.

> I like this idea, but there are still some problems to be solved. The
> major problem with grafts is still the initialization of objects. What
> to do with constructors which require parameter?

Good point. My new suggestion at the end covers it.

> An other issue I see is the question of introducing to much additional
> syntax. It could be reduced to something like:
> 
> private $counter : Counter [use] {  //with or without use?
>     public current();
>     public reset();
> }

I don't see the above having less syntax than my suggestion. "as" or ":"
is both syntax. I doubt, I would rather stick to a keyword already in
the language in similar semantics. For Comparison, my suggestion was:

>>   use Counter as private $counter{
>>     public current();
>>     public reset();
>>   }


> But now anonymous grafts aren't possible anymore and actually, Grafts
> had been design without an identity own their own.

Yes and I don't think anonymous Grafts would be a good idea. They would
make access to grafts complicated and significantly limited including
valid use cases. Being explicit instead of implicit helps here in my eyes.

> On the other hand,
> this notation could introduce the possibility for advanced initialization:
> 
>     private $cntInitValue;
>     public function __construct($cntValue) {
>         $this->cntInitValue = $cntValue;
>     }
> 
>     private $counter : Counter(cntInitValue) {
>         public current();
>         public reset();
>     }

I don't think that's a good idea. I admit it's very close to my
suggestion, but now it reached a point, where it does something very
familiar, namely creating an new object, using a very unfamiliar way and
also new syntax. So I make a new suggestion that puts everything much
closer to present PHP:

> class QueueTicketPrinter{
>     private $counter {
>         public current();
>         public restart() from reset();
>     };
>
>     public function __construct($cntValue) {
>         $this->counter = new Counter( $cntValue );
>     }
>
>     public function takeNumber(){
>         print 'your number is ".$this->current();
>         $this->counter->inc();
>     }
> }

And two syntax variants:

Variant 1:
>     private $counter use {
>         public current();
>         reset() as public restart();
>     };

Variant 2:
>     private $counter delegate {
>         public current();
>         public restart() to reset();
>     };


This suggestion requires a new runtime Error/Exception for cases when a
method of QueueTicketPrinter is called that is delegated to a method
that $counter does not implement.

> Every time you just like to compose a class from different kinds of
> behaviors Traits are superior. 

More powerful yes, superior no. Delegation and inheritance (counting
traits as a variant of inheritance) both allow functionality re-use but
both also resemble a trade-off between flexibility and "breakability".
Inheritance is more flexible, but can easily break, especially when
inheritance structures grow. Delegation is less flexible, but can't
break (from reuse), even in large structures. So both are justified.

Best regards

Christopher

P.S. I should mention that I do not have any insight of the actual
implementation of PHP. So if I suggest something insensibly hard to
implement, just shout :).