Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92438
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.115 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <D33531D4.6D3F3%fsb@thefsb.org>
 <CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
 <D3357498.6D41E%fsb@thefsb.org>
 <CAFMT4NrN=q1ZBUXGBPquFTVVaJpoHfbhTDKU2LMZY1C5tu4FKg@mail.gmail.com>
 <D335A5AA.6D579%fsb@thefsb.org> <57103A46.6040803@garfieldtech.com>
 <CAFMT4NpOCf3VON01_3n4xMKVOhEVNL-CsRm5gYOgogEnwt=XvQ@mail.gmail.com>
 <5710BA79.5060108@lsces.co.uk> <57110DC5.8000007@garfieldtech.com>
 <571338E6.50507@fleshgrinder.com> <57145AF7.7060607@garfieldtech.com>
 <57149405.2040701@lsces.co.uk> <57151210.7040704@garfieldtech.com>
 <57152641.7050602@gmail.com>
Message-ID: <571597F8.8070102@thefsb.org>
Date: Mon, 18 Apr 2016 22:29:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <57152641.7050602@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration
From: fsb@thefsb.org (Tom Worster)

On 4/18/16 2:24 PM, Stanislav Malyshev wrote:

> I would like to note in general that following the latest fashion in
> academic development is not always a good idea for PHP. It's fine when
> you experiment with academic languages, but when you have language that
> a) focused on simplicity and low entrance barrier and b) is in
> production use by millions and has 20 years of existing practices,
> libraries and habits, we have to be a bit more wary, I think. I am *not*
> saying we should not improve, or ignore academic developments, I am
> saying that we should be careful with not jumping to the idea-of-the-day
> bandwagon too fast, before it is clear it is good and necessary for PHP.

...

I agree with Stas, not just this paragraph but pretty all of the email.

Within the context of today's PHP language, practices, and the tried and 
true libraries and frameworks we rely on, I don't know how, for certain 
necessary semantics, to improve on Something or null return contracts.

I all honesty, I've looked for alternatives that satisfy a specific type 
but I can't find anything better.

For example, I use the active record ORM from the Yii 2 framework. My 
User model class therefore extends ActiveRecord. If I search for a User 
record matching given criteria (e.g. an email address) the parent class 
needs a generic way represent that no matching record exists and that 
this is not an exception.

The convention in PHP is to return null in this situation. I have tried 
to imagine how the search method might return an instance of the User 
model class that represents "not a user record", i.e. the absence of any 
user matching the search criteria. PHP's version of OOP seems not to 
have a intrinsic feature for a function to return an object with type 
Something but void of any Something object instance.

If PHP has nothing to model this, what convention can we invent as a 
workaround to *encode* "empty" in an actual instance of ActiveRecord or 
any subtype? A magic property can conflict with the app's model 
attributes. But an ActiveRecord::isEmpty() method could work. This 
satisfies the desire to return a specific subtype of ActiveRecord (e.g. 
User) but it also introduces hazardous complexity: what do you do with 
an instance in which the model's attributes, including primary key,  are 
valid but isEmpty() returns true, or vise versa.

Moreover, in what way is this better than returning PHP null? What have 
we gained with this isEmpty() conventions?

Tom