Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96881
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABdc3Wp2Z_BW9hW1mniqR2jpCGVqH4fgGqyrKuHBjeN8rrTHoQ@mail.gmail.com>
References: <CABdc3Wpx37dV28Z55kejhzFMpxADp-aN-oO8KWSriV_L59VAiw@mail.gmail.com>
 <CAL=_i_kTWEbfaANN99WFAnxf3RcvtpFozyqNn=ZZgVGQwwUa0Q@mail.gmail.com>
 <0c171a20-c72d-4157-1117-6628a52dd1f0@gmx.de> <CANUQDCgHMu9X=mWZtAumCBOdGKYaenmf2Hz1rAspZDGnfCTuuA@mail.gmail.com>
 <CAFMT4Noa2=4kHXuANx0Gq7p7dGG4BjUf7qgFwJvk6+bp_kx55Q@mail.gmail.com>
 <CAL=_i_=8fSytaskkWS6qK9KFU-5FneGXyTm6CE_T+u8RRmBAGA@mail.gmail.com>
 <CAFMT4Npz8qncXAFBPitU87=DOC-3v+DQcGxdzoHN3oQUmbyK8w@mail.gmail.com>
 <CAL=_i_m=fyouC20wTn0Lx8GYLrfwtmHg-bfTx0ais4dEN0xNqg@mail.gmail.com> <CABdc3Wp2Z_BW9hW1mniqR2jpCGVqH4fgGqyrKuHBjeN8rrTHoQ@mail.gmail.com>
Date: Mon, 14 Nov 2016 10:16:16 +0100
Message-ID: <CABdc3Wpe9_S=0wi5tMGw8LpyqKPAwWVPXjM38UsSxz5W4oyKaw@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: Levi Morrison <levim@php.net>, Niklas Keller <me@kelunik.com>, 
	"Christoph M. Becker" <cmbecker69@gmx.de>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114363c6c79d4805413f4ac7
Subject: Re: [PHP-DEV] [RFC][VOTE] Object typehint
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a114363c6c79d4805413f4ac7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C5=82

2016-11-14 9:53 GMT+01:00 Micha=C5=82 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=C5=82
>
> 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 enu=
ms
>> 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=C5=82 Brzuchalski
>>> >> >> > <michal@brzuchalski.
>>> >> >> .com>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> Hi everyone,
>>> >> >> >>
>>> >> >> >> Two weeks have passed since this RFC was put to discussion her=
e.
>>> >> >> >>
>>> >> >> >> 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 week=
s
>>> 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=C5=82 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 kn=
ow
>>> >> the answer here.
>>> >
>>> >
>>>
>>> I strongly disagree here; once we add `object` return type covariance
>>> it cannot easily be removed.
>>>
>>
>>
>
>
> --
> regards / pozdrawiam,
> --
> Micha=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--001a114363c6c79d4805413f4ac7--