Re: [RFC][VOTE] Object typehint

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 <michal@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 > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com