Re: [RFC][VOTE] Object typehint

From: Date: Thu, 10 Nov 2016 12:20:56 +0000
Subject: Re: [RFC][VOTE] Object typehint
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-96815@lists.php.net to get a copy of this message
On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins <pthreads@pthreads.org> wrote: > Morning Levi, > >> There is a future compatibility issue of this same type with >> object: > > If that is an issue, it is for future RFC's to deal with. > > Cheers > Joe > > > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison <levim@php.net> wrote: >> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller <me@kelunik.com> wrote: >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de>: >> > >> >> On 09.11.2016 at 17:28, Joe Watkins wrote: >> >> >> >> > I want to explain why I voted no on this: >> >> > >> >> > I think it's significantly less useful without variance, variance >> >> > is >> >> > something that is usually difficult to achieve in PHP, but not for >> >> > this >> >> > feature in particular. >> >> >> >> Can you please elaborate what you mean with variance? I see some >> >> practical use cases for covariance of a method with return type object, >> >> but I don't see how contravariance could be achieved for parameters of >> >> type object. >> >> >> >> If your suggestion is only about invariance of object return types, I'm >> >> not sure if this very special case would make sense (for consistency >> >> reasons). >> >> >> > >> > We already have it for iterable -> array. We would have it for all other >> > types if there wouldn't be an implementation issue. >> > >> > Regards, Niklas >> > >> > Cheers, >> >> Christoph >> >> >> >> > I absolutely want it, but I want it to be properly useful. >> >> > >> >> > If the RFC were halted and patched to include variance, I'd +1 >> >> > it. >> >> > >> >> > Cheers >> >> > Joe >> >> > >> >> > On Sun, Nov 6, 2016 at 5:28 PM, MichaÅ‚ Brzuchalski >> >> > <michal@brzuchalski. >> >> .com> >> >> > wrote: >> >> > >> >> >> Hi everyone, >> >> >> >> >> >> Two weeks have passed since this RFC was put to discussion here. >> >> >> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2. >> >> >> >> >> >> Voting starts today, 2016-11-06, and will close after two weeks on >> >> >> the >> >> >> Sunday 2016-11-20 at midnight. >> >> >> >> >> >> The RFC and voting widget can be found here: >> >> >> https://wiki.php.net/rfc/object-typehint >> >> >> >> >> >> It's a normal 2/3 majority required vote. >> >> >> >> >> >> Thanks! >> >> >> -- >> >> >> regards / pozdrawiam, >> >> >> -- >> >> >> MichaÅ‚ Brzuchalski >> >> >> about.me/brzuchal >> >> >> brzuchalski.com >> >> >> >> >> > >> >> >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: >> >> http://www.php.net/unsub.php >> >> >> >> >> >> In a return type context iterable can be changed to >> Traversable or >> array; it cannot be changed to >> Collection as we cannot guarantee >> at compile-time that Collection implements Traversable. >> >> There is a future compatibility issue of this same type with objectýšÒß >> ªµª ‘Â_š: >> right now the only user-definable types are objects. However, enums >> are an often requested feature and they may not be objects. Thus we >> wouldn't be able to guarantee that Foo is an object. >> There is a >> draft RFC with a patch for enums and expect it will come to a >> discussion soon, so I don't think we'll have to wait very long to know >> the answer here. > > I strongly disagree here; once we add object return type covariance it cannot easily be removed.

« previous php.internals (#96815) next »