On 5/23/2017 9:25 PM, Rasmus Schultz wrote:
> This parameter type widening RFC, I didn't know about, but I have a remark.
> 
> The feature, as implemented, will allow accidental omission of type-hints,
> will it not?
> 
> Previously, the implements keyword guaranteed a correctly type-hinted
> implementation - it's now possible to (purposefully, obviously, in certain
> rare cases) omit type-hints by accident, making the implements keyword much
> less (or not any) of a guarantee that the interface is implemented
> correctly.
> 
> The addition of an explicit "mixed" or "any" pseudo-type would have made
> this possible, without losing the guarantee that the implements keyword
> used to provide - that is, it would have been possible to have this feature
> for the few cases where it's useful, without affecting safety in the
> majority of other cases where it's not.
> 
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
> 
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
> 
> The RFC page doesn't link to any discussion, and the Github thread was shut
> down after some negative remarks.
> 
> I didn't see a discussion or a vote here on internals - did I miss
> something? Where or how did this get discussed and passed? Are these
> discussions happening somewhere else besides internals now?
> 

Hey Rasmus!

- Discussion: https://marc.info/?t=147972136200001&r=1&w=2

I also had a look at the GitHub discussion, and I think that the things
that were written there have nothing to do with your concern. The people
commenting there simply did not understand LSP.

That being said, your remark is actually more than legit and I have to
agree that this is indeed just crying out for static analysis tools to
add more warnings to code.

I would very much love to see "any", but introducing yet another keyword
is imho not a good idea. We have already an extremely mixed up
terminology, hence, "mixed" would do and match the existing grammar of
PHP nicely.

There is time left for PHP 7.2 (20. July I think), maybe this is fixable
before that? I guess this will require an RFC too though.

-- 
Richard "Fleshgrinder" Fussenegger

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to