Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99212
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.218 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADqTB_hs85GU63D5pB7ArHBhJ=0CK_aUYtPiOvokn4OeyFXTRA@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>
Date: Sun, 28 May 2017 14:27:39 +0200
Message-ID: <CANUQDChF3BVkBUH7BOjXwNQapvzBQHwExZMQbeRYpn44jcCXfA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: Dan Ackroyd <danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113ce09a5068b2055094b2ed"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: me@kelunik.com (Niklas Keller)

--001a113ce09a5068b2055094b2ed
Content-Type: text/plain; charset="UTF-8"

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

--001a113ce09a5068b2055094b2ed--