[RFC][VOTE] Object typehint

> 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 <pthreads@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 <levim@php.net> wrote: >> >>> 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. >>> >> >> > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com >

> 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 <pthreads@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 <levim@php.net> wrote: > > > >> 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. > >> > > > > > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com