Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96813
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.176 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CANUQDCgHMu9X=mWZtAumCBOdGKYaenmf2Hz1rAspZDGnfCTuuA@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>
Date: Thu, 10 Nov 2016 05:12:35 -0700
Message-ID: <CAFMT4Noa2=4kHXuANx0Gq7p7dGG4BjUf7qgFwJvk6+bp_kx55Q@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, Joe Watkins <pthreads@pthreads.org>, 
	=?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][VOTE] Object typehint
From: levim@php.net (Levi Morrison)

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 thi=
s
>> > 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@brzuch=
alski.
>> .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 th=
e
>> >> 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 know
the answer here.