# [RFC][VOTE] Object typehint - Thread: https://externals.io/message/96741 - Original archive: https://news-web.php.net/php.internals/96741 - Started by michal@brzuchalski.com on 2016-11-06T17:28:22+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #96741 — michal@brzuchalski.com — 2016-11-06T17:28:22+00:00 URL: https://externals.io/message/96741#96741 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 --- ## #96791 — Joe Watkins — 2016-11-09T16:28:50+00:00 URL: https://externals.io/message/96741#96791 · In reply to: #96741 Morning Internals, 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. 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 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 --- ## #96793 — michal@brzuchalski.com — 2016-11-09T19:34:40+00:00 URL: https://externals.io/message/96741#96793 · In reply to: #96791 Hi Joe, If that's gonna improve feature I'll be happy to patch and then restart voting. I hope it's gonna satisfy more voters :) I'll put RFC: On hold, then apply patch, draft some info in RFC and then set up new voting. Cheers, 2016-11-09 17:28 GMT+01:00 Joe Watkins : > Morning Internals, > > 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. > > 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 > […] > > > […] > > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com --- ## #96796 — Christoph M. Becker — 2016-11-09T20:53:30+00:00 URL: https://externals.io/message/96741#96796 · In reply to: #96791 > 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). 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 > wrote: > > > […] --- ## #96797 — Christoph M. Becker — 2016-11-09T21:10:05+00:00 URL: https://externals.io/message/96741#96797 · In reply to: #96796 > > > > […] > > 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 ^^ should be covariance > not sure if this very special case would make sense (for consistency > reasons). > > Cheers, > Christoph > > > […] --- ## #96808 — Niklas Keller — 2016-11-10T09:11:49+00:00 URL: https://externals.io/message/96741#96808 · In reply to: #96796 2016-11-09 21:53 GMT+01:00 Christoph M. Becker : > > > > […] > > 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 > > > […] > .com> > > […] --- ## #96809 — Peter Cowburn — 2016-11-10T09:52:33+00:00 URL: https://externals.io/message/96741#96809 · In reply to: #96808 > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker : > > > […] > is > > […] > > 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, > > […] > The vote appears to be closed right now, did I miss an announcement? > > > […] --- ## #96811 — Joe Watkins — 2016-11-10T10:38:40+00:00 URL: https://externals.io/message/96741#96811 · In reply to: #96809 Morning Peter, > I'll put RFC: On hold, then apply patch, draft some info in RFC and then set up new voting. Just a few messages up from here ... Would you prefer a new thread to make that announcement (I think it may be better) ? Cheers Joe On Thu, Nov 10, 2016 at 9:52 AM, Peter Cowburn wrote: > > > > > > […] > > The vote appears to be closed right now, did I miss an announcement? > > > > […] --- ## #96812 — Peter Cowburn — 2016-11-10T11:09:18+00:00 URL: https://externals.io/message/96741#96812 · In reply to: #96811 > Morning Peter, > > > […] > set up new voting. > > Just a few messages up from here ... > > Would you prefer a new thread to make that announcement (I think it may be > better) ? > No, it's fine IMO (and is the norm) to just have a message in the [VOTE] thread. I simply missed Michał saying he was closing the vote, when skimming the thread this morning, so thanks for pointing it out. :) > > Cheers > Joe > > On Thu, Nov 10, 2016 at 9:52 AM, Peter Cowburn > wrote: > > > […] --- ## #96813 — Levi Morrison — 2016-11-10T12:12:35+00:00 URL: https://externals.io/message/96741#96813 · In reply to: #96808 > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker : > > > […] > > 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, > > […] 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. --- ## #96814 — Joe Watkins — 2016-11-10T12:18:30+00:00 URL: https://externals.io/message/96741#96814 · In reply to: #96813 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 > > > […] > is > > […] > this > > […] > > […] > the > > […] > > 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. --- ## #96815 — Levi Morrison — 2016-11-10T12:20:56+00:00 URL: https://externals.io/message/96741#96815 · In reply to: #96814 > Morning Levi, > > > […] > > If that is an issue, it is for future RFC's to deal with. > > Cheers > Joe > > > > > […] > > I strongly disagree here; once we add `object` return type covariance it cannot easily be removed. --- ## #96817 — Joe Watkins — 2016-11-10T12:30:12+00:00 URL: https://externals.io/message/96741#96817 · In reply to: #96815 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 5:18 AM, Joe Watkins > wrote: > > […] > variance > > […] > object, > > […] > of > > […] > I'm > > […] > other > > […] > > I strongly disagree here; once we add `object` return type covariance > it cannot easily be removed. --- ## #96880 — michal@brzuchalski.com — 2016-11-14T08:53:07+00:00 URL: https://externals.io/message/96741#96880 · In reply to: #96817 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 : > 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 > > > > > […] > > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com --- ## #96881 — michal@brzuchalski.com — 2016-11-14T09:16:16+00:00 URL: https://externals.io/message/96741#96881 · In reply to: #96880 Hi All, again with bad news, sorry for the mess, the argument override is allowed in wrong direction what beaks Liskov's principle so need to stop it again. Hold on for a while, don't loose faith. regards, Michał 2016-11-14 9:53 GMT+01:00 Michał Brzuchalski : > 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 : > > > […] > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com --- ## #96882 — Joe Watkins — 2016-11-14T09:20:16+00:00 URL: https://externals.io/message/96741#96882 · In reply to: #96881 Sorry people, my fault :( On Mon, Nov 14, 2016 at 9:16 AM, Michał Brzuchalski wrote: > Hi All, > > again with bad news, sorry for the mess, the argument override is allowed > in wrong direction what beaks Liskov's principle so need to stop it again. > Hold on for a while, don't loose faith. > > regards, > Michał > > 2016-11-14 9:53 GMT+01:00 Michał Brzuchalski : > > > […] > enums > > […] > `object`: > > […] > wrote: > > […] > here. > > […] > weeks > > […] > or > > […] > `object`: > > […] > know > > […] > > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com --- ## #96883 — Josh Di Fabio — 2016-11-14T09:20:23+00:00 URL: https://externals.io/message/96741#96883 · In reply to: #96880 On Mon, Nov 14, 2016 at 8:54 AM Michał Brzuchalski wrote: > 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 This section describes covariance of method arguments. Is this a mistake? Should this be contravariance? Covariant arguments go against LSP. > > 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 : > > > […] > enums > > […] > `object`: > > […] > wrote: > > […] > wrote: > > […] > for > > […] > parameters > > […] > types, > > […] > consistency > > […] > +1 > > […] > here. > > […] > or > > […] > `object`: > > […] > know > > […] > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com P.S. Apologies for the non-plaintext email. --- ## #96884 — michal@brzuchalski.com — 2016-11-14T09:34:20+00:00 URL: https://externals.io/message/96741#96884 · In reply to: #96883 Yes, function/method arguments should be contravariant. I'm sorry I haven't got caught anyone to review after Joe's patch. I promise to remember about that next time. 2016-11-14 10:20 GMT+01:00 Josh Di Fabio : > On Mon, Nov 14, 2016 at 8:54 AM Michał Brzuchalski > wrote: > > > […] > > This section describes covariance of method arguments. Is this a mistake? > Should this be contravariance? Covariant arguments go against LSP. > > > […] > > > P.S. Apologies for the non-plaintext email. > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com