2008/2/19, Lars Strojny <[EMAIL PROTECTED]>:
> 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.
Well, it is aliasing, not renaming.
Think only the exclusion of a method will break the interface, but
since the interface is propagated to the class the class has to take
care that it is implemented properly and an error will be raised if it
is not implemented correctly at compile time.

Let say I modify the example like this:

class MyHelloWorld {
  use SayHello {
    !sayHello
  }
}

the compiler will give an error that sayHello is missing since
MyHelloWorld states it is implementing IHello.

> 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.
Yes it is definitely a conceptual problem to propagate interfaces,
because the notation does not imply this behavior and you can not see
the interfaces added by the trait.
Therefore, I'm with you, interface propagation might be a point to not
be included.

Kind Regards
Stefan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to