Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79215
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.50 as permitted sender)
Message-ID: <5476D7FD.3020003@gmail.com>
Date: Wed, 26 Nov 2014 23:51:25 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: 'Levi Morrison' <levim@php.net>, 
 'internals' <internals@lists.php.net>
References: <CAFMT4Npco8sQ-+5hpUNa3pu5L2q7mnCVnsCjZee=NbNDrkwLUw@mail.gmail.com> <003701d008da$0c60d630$25228290$@tutteli.ch>
In-Reply-To: <003701d008da$0c60d630$25228290$@tutteli.ch>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: AW: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>> I've also used it because it can adequately show the differences in how each of the following options work:
>>
>>   1. Do covariant return types; check them at definition time
>>   2. Do covariant return types; check them at runtime
>>   3. Do invariant return types; check them at definition time

My opinion is that on some level it doesn't matter too much. The type
errors by itself are quite rare among the errors one can make in the
program, and usually found and fixed rather easily [1]. Errors in return
types - i.e. mismatch between declaration and code in your own code
located compactly on the screen - would be even rarer. Errors where the
difference is between covariant and invariant classes - and thus use
cases where such usage is helpful to prevent them - in my opinion, would
be so vanishingly rare that most people would never really need it, and
probably would spend much more time figuring out the right types to set
on the return values that it will ever save them on debugging. I suspect
except for the simplest cases these would be used more for
documentation/"feel good" purposes than for anything else.

Thus, taken practically, I think the option that has minimal impact on
the existing code, its speed and complexity should be taken. If it
requires reducing the expressiveness to the option 3, I don't think it
is a huge loss.

I'm not sure though what is involved in "runtime checking" and what
would be the consequences - i.e., what will be checked at runtime and
which runtime will it be? In PHP, mostly everything is "runtime"
strictly speaking, so some clarification here would help.

[1] E.g. check out this one: http://vimeo.com/74354480
There is a vivid debate about many conclusiong derived there but I think
empirical evidence is worth considering however is your stand on the
conclusions.
-- 
Stas Malyshev
smalyshev@gmail.com