Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Message-ID: <49203DF2.1020006@stefan-marr.de>
Date: Sun, 16 Nov 2008 16:36:18 +0100
Reply-To: php@stefan-marr.de
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Christopher Vogt <christopher.vogt@rwth-aachen.de>
CC: internals@lists.php.net
References: <002b01c92d67$ae92fdc0$0bb8f940$@de> <79.C8.07308.CDE4C194@pb1.pair.com>
In-Reply-To: <79.C8.07308.CDE4C194@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: php@stefan-marr.de (Stefan Marr)

Hi,

Christopher Vogt schrieb:
> Hej everybody,
> 
> I really liked to see the Grafts proposal.
Well, I'm still in love with the more powerful (because they are 
interweaveable(breakable)) Traits ;)


> The Grafts proposal, however, suffered a little from being born out of
> traits, I think. Something similar to Grafts is already possible in
> current php, but it is not very beautiful. If we start from there
> however, Grafts could become very helpful syntactic sugar. 
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. Nevertheless, from my perspective forwarding (aka 
delegation) is a very common concept in OOP which would be worth to be 
supported by a special syntax.

> class QueueTicketPrinter{
>   use Counter as private $counter{
>     public current();
>     public reset();
>   }
>   public function takeNumber(){
>     print 'your number is ".$this->counter->current();
>     $this->counter->inc();
>   }
> }
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?
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();
}

But now anonymous grafts aren't possible anymore and actually, Grafts 
had been design without an identity own their own. On the other hand, 
this notation could introduce the possibility for advanced initialization:

class QueueTicketPrinter{
     private $cntInitValue;
     public function __construct($cntValue) {
         $this->cntInitValue = $cntValue;
     }

     private $counter : Counter(cntInitValue) {
         public current();
         public reset();
     }

     public function takeNumber(){
         print 'your number is ".$this->counter->current();
         $this->counter->inc();
     }
}



> Finally, can somebody provide a sensible use case for traits, that
> cannot be solved with Grafts? I am sure there is, but I am currently
> lacking one.
Every time you just like to compose a class from different kinds of 
behaviors Traits are superior. The use cases discussed in literature are 
class hierarchies for collection classes and streams. For both 
hierarchies, the interweaving of methods from different traits is a 
helpful property to build all variations of semantics.


Kind Regards
Stefan