Re: [RFC][VOTE] Object typehint

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.