Re: RFC: Traits for PHP

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