Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91852
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
To: internals@lists.php.net
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
 <2070425.mznTmPgxij@mcmic-probook> <56F15D31.5070405@garfieldtech.com>
 <C67770FC-F8E9-4667-89CC-4F6941403F66@heigl.org>
Message-ID: <56F175F8.6080805@gmail.com>
Date: Tue, 22 Mar 2016 16:42:32 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <C67770FC-F8E9-4667-89CC-4F6941403F66@heigl.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time
 polymorphic methods
From: rowan.collins@gmail.com (Rowan Collins)

Andreas Heigl wrote on 22/03/2016 16:25:
>> In the PHP 7 and typing presentations I've been giving[1], I've advocated either:
>> >
>> >1) Throw an exception if the rest of the code is going to break anyway.
>> >2) Define an empty object with matching interface if you want an equivalent of 0/empty string.
> When code expects a user-object but can't get one it'll break. Throwing an exception makes it easy to react to that. But when the code has to check whether that's a mocked user object or a real user object it's about as good as returning null or eliminating the return type altogether as you have to build the code around that returned value you can't really use.

It depends on the context; sometimes, you are right, you would end up 
checking for validity early anyway, and an exception would be easier. 
However, the Null Object Pattern can simplify logic significantly where 
there is an obvious "null behaviour" that it can implement.

Wikipedia gives the example of a recursive tree operation having to 
check for missing child nodes 
(https://en.wikipedia.org/wiki/Null_Object_pattern#Example); 
initialising the child nodes with Null Objects eliminates the check.

The key point is that in some cases, the calling code *won't* break, 
because the Null Object can still adhere to the interface, just by 
returning appropriate empty values. In the tree node case, a 
NullTreeNode would always return further NullTreeNodes as children, a 
sub-tree size of 0, and either no-op or error if you attempted modification.

Regards,
-- 
Rowan Collins
[IMSoP]