> > So just to get this straight: we remove the sentence (because it sounds > weird to have it in a standard), but we agree that it's still completely > fine if implementations have extra *optional* parameters right?
If it were completely fine, we wouldn't remove the sentence, no? Optional parameters are *not* fine. It hurts interoperability. If a consumer passes them, it assumes a concrete implementation. If the implementation is swapped, they might be ignored, but it's even worse if that implementation also has optional parameters, then they might be interpreted wrongly. Because we obviously want to keep all containers compatible. They *are* still compatible, because these parameters are *optional*, so don't have to be provided. I just don't want to force implementations to have exactly 1 parameter, > which doesn't make sense in PHP and in OOP in general > Yes, it does make sense. If you only code to interfaces, optional parameters that are not defined in the interface do not make sense. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8dc6ee8a-7459-4a29-91d3-6ea6fa028c69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
