Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96880
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: <CAL=_i_m=fyouC20wTn0Lx8GYLrfwtmHg-bfTx0ais4dEN0xNqg@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>
Date: Mon, 14 Nov 2016 09:53:07 +0100
Message-ID: <CABdc3Wp2Z_BW9hW1mniqR2jpCGVqH4fgGqyrKuHBjeN8rrTHoQ@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=001a1134c26a06245305413ef877
Subject: Re: [PHP-DEV] [RFC][VOTE] Object typehint
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a1134c26a06245305413ef877
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 enum=
s
> 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 f=
or
>> >> >> > 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 parameter=
s
>> 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 consisten=
cy
>> >> >> 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 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=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` o=
r
>> >> `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 kno=
w
>> >> the answer here.
>> >
>> >
>>
>> I strongly disagree here; once we add `object` return type covariance
>> it cannot easily be removed.
>>
>
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--001a1134c26a06245305413ef877--