> > I still believe this information should be added to the RFC as the risk > of adding new methods to an interface which collide with existing > methods in implementations of that interface is very real, though I > agree with Deleu that this BC impact is not so much of the RFC, but of > what can happen once the RFC would be accepted. > > While I can understand the tendency to defer this question to "that's an > issue for userland when userland adds new methods to existing > interfaces" (or PHP itself if new methods would be added to PHP native > interfaces), I don't think that's fair as this RFC is the one which > opens the door to that possibility. > > Smile, > Juliette >
Adding a new method to an existing interface is already a BC break today and requires a major version bump, otherwise implementers of the interface will get a fatal error because they're missing implementing all methods of an interface. We can call this a "Userland BC Path" (how a userland can make a BC to other users). This RFC doesn't open this door, it actually creates a path which makes this Userland BC Path less "damaging". If an interface provider adds a new method to an interface (already a BC Break), but does so by adding a default implementation, then such a change will break less code than just adding a method without a default implementation because only code that already had the exact same method name would now break. One can argue that this change might make it so that users start considering adding methods with default implementation as not-so-much-a-bc-break and do so without bumping a major version, in which case this RFC could be said to "open the door for some users to start introducing BC-breaks without bumping major version" because they consider it a much smaller BC break, but it can't be said to open the possibility. Does this make sense? -- Marco Deleu
