Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96884 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55141 invoked from network); 14 Nov 2016 09:34:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Nov 2016 09:34:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=michal@brzuchalski.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=michal@brzuchalski.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender) X-PHP-List-Original-Sender: michal@brzuchalski.com X-Host-Fingerprint: 188.165.245.118 ns220893.ip-188-165-245.eu Received: from [188.165.245.118] ([188.165.245.118:58976] helo=poczta.brzuchalski.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E6/02-34859-72589285 for ; Mon, 14 Nov 2016 04:34:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by poczta.brzuchalski.com (Postfix) with ESMTP id C37C22984239 for ; Mon, 14 Nov 2016 10:34:28 +0100 (CET) Received: from poczta.brzuchalski.com ([127.0.0.1]) by localhost (poczta.brzuchalski.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzvfw96_2ESa for ; Mon, 14 Nov 2016 10:34:26 +0100 (CET) Received: from mail-wm0-f41.google.com (unknown [74.125.82.41]) by poczta.brzuchalski.com (Postfix) with ESMTPSA id C88AB298423A for ; Mon, 14 Nov 2016 10:34:21 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id a197so86632929wmd.0 for ; Mon, 14 Nov 2016 01:34:21 -0800 (PST) X-Gm-Message-State: ABUngvfhC5mWRoFEvMZCAcUZ69I//Pqjx9NFw7Or5pSLDqpnyyudGqKEYiAGcHHhnDapstsWng993StRhF4R9A== X-Received: by 10.28.199.71 with SMTP id x68mr8778953wmf.34.1479116061480; Mon, 14 Nov 2016 01:34:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.103.10 with HTTP; Mon, 14 Nov 2016 01:34:20 -0800 (PST) In-Reply-To: References: <0c171a20-c72d-4157-1117-6628a52dd1f0@gmx.de> Date: Mon, 14 Nov 2016 10:34:20 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Josh Di Fabio Cc: Joe Watkins , Levi Morrison , Niklas Keller , "Christoph M. Becker" , PHP Internals List Content-Type: multipart/alternative; boundary=94eb2c0d77586d1fc705413f8b05 Subject: Re: [PHP-DEV] [RFC][VOTE] Object typehint From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --94eb2c0d77586d1fc705413f8b05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, function/method arguments should be contravariant. I'm sorry I haven't got caught anyone to review after Joe's patch. I promise to remember about that next time. 2016-11-14 10:20 GMT+01:00 Josh Di Fabio : > On Mon, Nov 14, 2016 at 8:54 AM Micha=C5=82 Brzuchalski > wrote: > >> Hi All, >> >> Id' like to anounce voting reset - will end in two weeks on 28.11.2016 a= t >> 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 > > This section describes covariance of method arguments. Is this a mistake? > Should this be contravariance? Covariant arguments go against LSP. > >> >> It means any `object` typehint or return type can be narrowed to more >> specified type (class name) similar to `iterable` pseudo-type but behave= s >> 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 : >> >> > Levi, >> > >> > You are assuming it would *need* to be removed :) >> > >> > Future RFC's must deal with the engine as they find it, as this RF= C >> > has done. >> > >> > If it is true that this would prohibit enums being non-objects, an= d >> > 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 wrote: >> > >> >> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins >> >> 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 >> wrote: >> >> >> >> >> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller >> wrote: >> >> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker > >: >> >> >> > >> >> >> >> 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 no= t >> for >> >> >> >> > this >> >> >> >> > feature in particular. >> >> >> >> >> >> >> >> Can you please elaborate what you mean with variance? I see so= me >> >> >> >> 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 a= ll >> >> 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 >> >> >> >> > > >> >> >> .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 PH= P >> >> 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= ` >> or >> >> >> `array`; it cannot be changed to `Collection` as we cannot guarant= ee >> >> >> 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, enum= s >> >> >> are an often requested feature and they may not be objects. Thus w= e >> >> >> 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=C5=82 Brzuchalski >> about.me/brzuchal >> brzuchalski.com > > > P.S. Apologies for the non-plaintext email. > --=20 regards / pozdrawiam, -- Micha=C5=82 Brzuchalski about.me/brzuchal brzuchalski.com --94eb2c0d77586d1fc705413f8b05--