Hi All, Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at midnight and requires 2/3 majority as previously.
There were improvements suggested by Joe Watkins and earlier by Nikita Popov to the patch. Those improvements are described on RFC under "Covariance" section https://wiki.php.net/rfc/object-typehint#covariance It means any `object` typehint or return type can be narrowed to more specified type (class name) similar to `iterable` pseudo-type but behaves covariant (more general type can be raplaced with narrowed one). P.S. I hope this improvement will bring more positive votes. regards, -- Michał 2016-11-10 13:30 GMT+01:00 Joe Watkins <pthre...@pthreads.org>: > Levi, > > You are assuming it would *need* to be removed :) > > Future RFC's must deal with the engine as they find it, as this RFC > has done. > > If it is true that this would prohibit enums being non-objects, and > I'm not certain that it does, then enums would have to be objects, if > that's how they find the engine. > > If your only concern is about a non-existent feature, then maybe > you're concern can be alleviated by the non-existent JIT (which does > partially exist): With a JIT, it doesn't much matter what represents enums > anyway. > > These are problems for the future, not today. > > Cheers > Joe > > On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison <le...@php.net> wrote: > >> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins <pthre...@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 <le...@php.net> wrote: >> >> >> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller <m...@kelunik.com> wrote: >> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker <cmbecke...@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. >> > > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
