Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99214
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 74.125.83.50 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANUQDChF3BVkBUH7BOjXwNQapvzBQHwExZMQbeRYpn44jcCXfA@mail.gmail.com>
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
 <CANUQDCjpjz8Wret1D6q9wb8rfBH4Xqc4uDqLTtuptkUdesUK4g@mail.gmail.com>
 <CADqTB_gbhw+pr+8dpkwdFwRTjiY4pk6fyeTnLUv72fBjTpArZA@mail.gmail.com>
 <CA+kxMuS=xBVQdyObpU2yK1jtr+3=JmAPJK-DaRKCZdCZRCfp2w@mail.gmail.com>
 <CADqTB_hs85GU63D5pB7ArHBhJ=0CK_aUYtPiOvokn4OeyFXTRA@mail.gmail.com> <CANUQDChF3BVkBUH7BOjXwNQapvzBQHwExZMQbeRYpn44jcCXfA@mail.gmail.com>
Date: Sun, 28 May 2017 15:25:09 +0200
Message-ID: <CADqTB_gc9BJnhL7fE-w51dYX760GSGsu6Vhc2d=DStLWRKXLRA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Dan Ackroyd <danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c0069c4eb6e180550957f63"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: rasmus@mindplay.dk (Rasmus Schultz)

--94eb2c0069c4eb6e180550957f63
Content-Type: text/plain; charset="UTF-8"

Alright, here's an example of code where a type-hint was accidentally left
out.

Before this change:

https://gist.github.com/mindplay-dk/e988902ed2d587dc05a1d8cb164b88c4/4d03babff16883a67accfb51b50e3d1aefb13a8a

And after this change:

https://gist.github.com/mindplay-dk/e988902ed2d587dc05a1d8cb164b88c4/03a4eec05b64185830785c5e684b3f94c1d62f5e

In other words, accidental omission of type-hints now means that this
faulty implementation is valid code.

And hopefully something will error, deep inside a call-stack, maybe in a
database-component that performs a type-check or something, but there is no
guarantee that it will error at all - if you passed an object that does
have a getID() method, because there's actually no type-check for the
Identity interface when calling the implementation, worst case, it actually
executes and quietly saves *something* to the database.

> No, interfaces exist to guarantee the caller can always pass a type XY
there.
> With type constraints removed in a subclass, this guarantee does not
break.

No, but you no longer get a type-check.

So yes, for *correct* code, there is no problem - but if you didn't write
the code correctly the first time, with this change, you may never even
know you've done something wrong, or you may have to drill through a much
larger call-stack and try to derive the source of the problem.

Before this change, a faulty implementation would simply get rejected.

To me, that's a setback that leads to harder-to-debug errors, and increases
learning-curve.

With an explicit mixed type-hint, you can still achieve what you want in
those rare cases where this simplified kind of contravariance is actually
useful, without also creating new problem cases for everyday coding.


On Sun, May 28, 2017 at 2:27 PM, Niklas Keller <me@kelunik.com> wrote:

> 2017-05-28 12:30 GMT+02:00 Rasmus Schultz <rasmus@mindplay.dk>:
>
>> > > So this breaks the expected behavior of interfaces.
>> >
>> > No it doesn't. It allows interfaces to use contravariance within PHP's
>> > type system, which is different from before, but it doesn't break
>> > anything.
>>
>> The RFC explicitly states that this is *not* contravariance.
>>
>
> Where does it state that? (The "true" in the future scope section should
> probably be replaced with "full".)
>
>
>> And if it's not clear, what I mean by "breaks the expected behavior", is,
>> as far as I understand, what this RFC actually does is it *removes*
>> expected behavior.
>>
>
> How does this *remove* expected behavior? Could you show a concrete
> example of code that breaks?
>
>
>> Correct me if I'm wrong, but really all this RFC does, is remove the
>> requirement that and implementation of an interface be type-hinted?
>>
>
> Correct, but not just for interfaces.
>
>
>> To me, that's "broken".
>>
>
> As said, please show a concrete example that breaks.
>
>
>> You're favorizing a very, very small number of isolated, valid use-cases -
>> by removing the normal, natural, expected constraint that an
>> implementation
>> be type-hinted as specified by the interface. It's part of the reason
>> interfaces even exist - and this simply ignores that and removes these
>> checks.
>>
>
> No, interfaces exist to guarantee the caller can always pass a type XY
> there. With type constraints removed in a subclass, this guarantee does not
> break.
>
>
>> In my opinion, this will very likely lead to a large number of accidental
>> type-hint omissions - and a very, very small number of actually useful
>> solutions to real problems.
>>
>> In my opinion, we can do much better than that, by adding a mixed
>> type-hint, which will ensure people aren't just accidentally omitting
>> type-hints and instead explicitly opting out of it to achieve parameter
>> widening. Solving this from the start also ensures we can have a clean
>> implementation of real contravariance in the future, without that being a
>> break change.
>
>
> You're, again, ignoring one of the major benefits of the RFC: Being able
> to move from explicit type checks to type declarations without breaking
> subclasses.
>
>
>> > Rasmus, not answering people's questions and instead saying emotional
>> > stuff suggesting other people have made historically bad decisions
>> > isn't a productive way to conduct a conversation.
>>
>> Okay, I'm emotional, sorry about that.
>>
>> But I think I'm pointing out a real problem and a real possible solution
>> that doesn't make the trade-offs of the current solution.
>>
>
> You haven't pointed out a real problem, yet.
>
> Regards, Niklas
>

--94eb2c0069c4eb6e180550957f63--