Thanks for clarifying the point. I've now opened a WIP PR with a first draft of how this bylaw should look in my opinion: https://github.com/php-fig/fig-standards/pull/1195
I'm not calling the vote yet, because I would like to gather opinions on it. Il giorno martedì 8 ottobre 2019 22:31:18 UTC+2, G. P. B. ha scritto: > > > > On Tue, 8 Oct 2019, 20:31 Alexandru Pătrănescu, <[email protected]> > wrote: > >> Hi Alessandro, >> >> But you can find example very easily. >> Take monolog: is not verifying that the $message is string but it's >> casting it to string later. >> If you send an object, it works now. After FIG releases a minor version, >> it will break. >> >> And I choose an object as example. But if they have strict_types=1. there >> will be a lot other cases that will stop functioning. >> >> I'm afraid it will require a major version FIG release and from how it >> looks like, it will require changes in libraries implementing it, not just >> changing one line in composer.json. >> Or am I missing something? >> >> Alex >> > > You are indeed missing something. > The interface is only a "base" contract that should be enforced by > implementations, but nothing prevents an implementation of accepting a > larger set of types (to stringable objects for example or something > completely different altogether), this is called contravariance. > > This is possible because it does not violate type safety (see Liskov > Substitution Principle i.e. LSP for more details). > This in turn means that implementation can safely upgrade from an > interface which does NOT define argument/parameter type to the one which > does specify them. > > This is however NOT the case with return types as only subsets of the > return type insure type safety (e.g. if return type is iterable an > implementation can define an array return type but the inverse is not true). > This is why adding return types is a BC-break and would need a new version > (which I argue is less of an issue with the upcoming covariant return types > in PHP 7.4, which allows implementation to add return type information > without breaking the contract it holds with the interface). > > Moreover, strict_types has nothing to do with this as its behaviour is > confined on whether or not the implementation uses it or not. > > I hope this clears it up. > > Best regards > > George Peter Banyard > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/827930a1-926e-4f39-8d7e-583aec557555%40googlegroups.com.
