Suggestion: Make no comment in the spec itself, but note in the metadoc
that "some existing implementations have extra optional parameters;
that's technically legal for backward compatibility but discouraged".
So that way Symfony's DIC, for instance, can remain compatible but
anyone writing a new implementation knows they're not supposed to do that.
--Larry Garfield
On 11/03/2016 03:42 AM, Matthieu Napoli wrote:
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 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/4176b4e2-9704-a6ab-2db8-e70912e7d94b%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
