Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <47BB6111.3080308@iamjochem.com>
Date: Wed, 20 Feb 2008 00:06:57 +0100
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Lars Strojny <lars@strojny.net>
CC: php@stefan-marr.de, internals@lists.php.net, =?ISO-8859-1?Q?=27Marcus?=
 =?ISO-8859-1?Q?_B=F6rger=27?= <helly@php.net>, =?ISO-8859-1?Q?=27Johanne?=
 =?ISO-8859-1?Q?s_Schl=FCter=27?= <johannes@php.net>, 
 'Sebastian Bergmann' <sb@sebastian-bergmann.de>,
 'Alexandre Bergel' <alexandre@bergel.eu>, 
 'Falko Menge' <falko.menge@hpi.uni-potsdam.de>,
 'Sara Golemon' <pollita@php.net>, derick@php.net
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <1203461114.24580.45.camel@localhost>
In-Reply-To: <1203461114.24580.45.camel@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: jochem@iamjochem.com (Jochem Maas)

Hi,

Lars Strojny schreef:
> Hi,
> 
> Am Montag, den 18.02.2008, 20:27 +0100 schrieb php@stefan-marr.de:
> [...]
>> To underpin this relationship, it is possible to declare that a Trait
>> implements an interface like this::
>>
>>  <?php
>>  interface IHello {
>>    public function sayHello();
>>  }
>>  
>>  trait SayHello implements IHello {
>>    public function sayHello() {
>>      echo 'Hello World!';
>>    }
>>  }
>>
>>  class MyHelloWorld {
>>    use SayHello;
>>  }
>>  
>>  $o = new MyHelloWorld();
>>  var_dump($o instanceof IHello);  // bool(true)
> 
> We have discussed that in IRC a bit and a lot of questions remain. The
> most important issue to me how to handle interface implementations in
> cases where methods from the interface implementing trait are renamed in
> the trait consumer class.
> I would propose to not overcomplicate things here and I see no real
> advantage in allowing traits to implement interfaces. I think also for
> the sake of conceptual integrity separating interfaces clearly from
> traits is a good idea: interfaces define structure while traits are
> function buckets. A class may use traits, may implement interfaces and
> may extend another class. This paradigm is pretty easy to explain to the
> user.

if a trait would could contain all the methods required to implement an interface
and a class uses it (the trait) and implements the relevant interface would it
(the interface) be satified?

also might it be an idea to allow a trait to specify that it implements an interface
for the purposes of development (errors triggered due to incorrect/incomplete implementation)
BUT not have the interface be carried to any classes that use the trait? ... classes
would have to explicitly state that they implement the interface and the fact that they
use a trait to do so would be irrelevant as far as 'where' the method came from.

interface iFoo {
	function doFoo();
}

// causes a compile time error due to missing function
//
trait tOneFoo implements iFoo {
	function doBar() { echo "hello"; }
}

// no compile time error
//
trait tTwoFoo implements iFoo {
	function doFoo() { echo "hello"; }
}

// using a trait that implements something without actually
// taking on the implementation
//
class cOneFoo {
	uses tTwoFoo;
}

// any iFoo method exclusion, aliasing, renaming
// in the following class would cause a compile time error
// due to missing iFoo function unless the class itself
// defined the method(s) in question
//
class cTwoFoo implements iFoo {
	uses tTwoFoo;
}

$one = new cOneFoo;
$two = new cTwoFoo;

// outputs: false, true
var_dump( ($one instanceof iFoo), ($one instanceof iFoo) );


something like the above might offer developers desired OO strictness
without actually blurring the boundaries between trait and interface
conceptually.

> 
> cu, Lars