Hi Niklas, I think there is a misunderstanding. - if you use the interface, then you use the parameters defined in that interface => so yes, you should NOT pass extra parameters (we agree on that, that doesn't make sense) - if you don't use the interface but the implementation directly, then it's OK to use the extra parameters (because you code against the implementation)
That's why OOP (and PHP) allows implementations to have more parameters than defined in the interface (because you stay compatible with the interface). Now we usually say "code against interfaces", because obviously that's much better. But here for container interoperability we have to consider the fact that not all frameworks can switch containers entirely. So some pieces of code will still use the implementation, that's why we have to be compatible with this. In any case, it doesn't make sense that an interface forbids extra optional parameters, because again OOP and PHP allows it. The question is whether we want to make that explicit or not in the document: I usually like explicit because it removes confusion for implementors (DIC authors). Matthieu Le Jeu 03 nov 2016, à 09:21, Niklas Keller a écrit : >> 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 a topic in > the Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/zY6FAG4-oz8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/php-fig/8dc6ee8a-7459-4a29-91d3-6ea6fa028c69%40googlegroups.com[1]. > For more options, visit https://groups.google.com/d/optout. Links: 1. https://groups.google.com/d/msgid/php-fig/8dc6ee8a-7459-4a29-91d3-6ea6fa028c69%40googlegroups.com?utm_medium=email&utm_source=footer -- 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1478162568.403962.775978177.0CD102FC%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
