On Wed, Feb 17, 2016 at 6:13 PM, Levi Morrison <le...@php.net> wrote:
> On Wed, Feb 17, 2016 at 12:48 PM, Kevin Gessner <kgess...@etsy.com> wrote: > > I don't think there is enough benefit from allowing traits to declare > > interfaces, but not propagating the interface out to classes that insert > the > > trait. It does provide an extra bit of enforcement on the trait's > methods, > > but the real value is in making that contract a part of the classes. > > I do agree that there is only a little benefit but I disagree that it > is "not enough". It's a quality of life change to an existing feature > that has no impact outside of that feature – sounds perfect to me. > > > In what situation would a class that inserts OuterIterator not want to > > declare the Iterator class? If every class that inserts the trait would > > also declare Iterator, it's needless repetition to require that both the > > class and the interface. > > Funny you should ask, because OuterIteratorTrait implementing > OuterIterator is actually a case where not all using classes will want > to be OuterIterators formally (just get the horizontal code reuse). > This is because I don't want to "leak" the inner iterator because it > is suppose to be abstracted. In these cases I use the syntax for using > a trait method under a different visibility. > Thanks, Levi, that makes sense. In my existing RFC, the case of changing the visibility of an included method would cause a fatal error (as the including class would no longer fulfill the interface), but that's not the only reasonable behavior. I can make this an open question in the RFC. It sounds like this summarizes most people's feelings at this point: adding interfaces to trait declarations is a reasonable change, but propagating the interfaces out to classes is contentious. I'm leaning at this point toward splitting the RFC ( https://wiki.php.net/rfc/traits-with-interfaces) into two proposals: 1. Allow a trait to declare one or more interfaces via the `implements` keyword on the trait definition. The engine will enforce that the trait's methods fulfill the interface. 2. A class, by including a trait that declares interfaces, will implicitly be declared to implement those interfaces. The vote on 2 would be moot if the vote on 1 does not pass. The combination of these is the existing RFC as a single proposal; I'd keep it as a single RFC with two proposals and two voting sections, voted separately but concurrently. It looks from history like multiple voted proposals on one RFC is OK, but please let me know if I'm violating protocol in some way. Would folks be amenable to that change to the RFC? Cheers -- Kevin
