Hi,
Lars Strojny schreef:
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
