Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104482 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 79480 invoked from network); 20 Feb 2019 23:50:44 -0000 Received: from unknown (HELO smtp.domeneshop.no) (194.63.252.55) by pb1.pair.com with SMTP; 20 Feb 2019 23:50:44 -0000 Received: from [82.144.227.204] (port=63204 helo=[127.0.0.1]) by smtp.domeneshop.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gwYaj-0000TP-AW for internals@lists.php.net; Wed, 20 Feb 2019 21:35:41 +0100 To: internals@lists.php.net References: <5f06eda3-5431-5469-badf-317e4eddd2fa@gmail.com> Message-ID: <7f41e512-9822-a562-c65f-eefe95b34bf6@braten.be> Date: Wed, 20 Feb 2019 20:35:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <5f06eda3-5431-5469-badf-317e4eddd2fa@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV][RFC] Allow void return type variance From: php@braten.be (=?UTF-8?Q?Terje_Br=c3=a5ten?=) Hi I think this is a great idea, and that it should be implemented. On 17/02/2019 16:36, Rowan Collins wrote: > > Instead, ": void" in PHP represents a *behavioural constraint* on the > function - it declares that within this function, anything of the form > "return $value" is to be treated as an error. In other languages, the > same constraint might be enforced by declaring the routine as a > "procedure" rather than a "function". > > As such, it is more appropriate to compare "void vs non-void" to "static > vs non-static", which is an invariant constraint - you can't over-ride a > static method with a non-static one, or vice versa. > I think this is flawed reasoning. Yes, you can view it as behavioral constraint on the current method, but I do not think that alone is a valid reason to impose the same constraint on all decendants of that class. Yes, "static" is an invaraint constraint, but I think we should consider this "void" constraint differently and not enforce that same invariance. The reason is that is fits very well with the Liskov substitution principle. Any decendant class can be subtituted safely in existing code, even if the decendant should be trying to return something. This also gives the least amount of surprise to a developer after RFC https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters has been implemented. Then developers will expect that return values can be different as long as the Liskov substitution principle holds. Terje Bråten.