Sorry people, my fault :( On Mon, Nov 14, 2016 at 9:16 AM, Michał Brzuchalski <mic...@brzuchalski.com> 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 <mic...@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 <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 > > > > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com >
