Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
Message-ID: <54889077.9020004@gmail.com>
Date: Wed, 10 Dec 2014 18:27:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com> <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me>
In-Reply-To: <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullsafe calls
From: rowan.collins@gmail.com (Rowan Collins)

Andrea Faulds wrote on 10/12/2014 17:19:
> Finally, this may encourage bad code. As someone helpfully pointed out in the reddit discussion (http://redd.it/2ot15u), this encourages breaking the Law of Demeter, i.e. that objects should only talk to their immediate friends. Usually, long chains of method calls across multiple objects are not a good idea, yet the main benefit of this RFC is to reduce the boilerplate needed for that scenario.

It's an interesting thought, but reading the Wikipedia article, I see 
that that "Law" has acknowledged downsides, and so code breaking it is 
not universally acknowledged as "bad". I actually think it's a better 
argument against chaining property access (which implies deep knowledge 
of structures) than against chaining methods (which may be completely 
abstract actions unrelated to structure).

In particular, long method chains are commonly associated with "fluent 
interfaces", which can be a very effective way of creating a 
Domain-Specific Language in an OOP system - database query builders, for 
instance, tend to use this approach. It may not even involve exposing 
additional objects at all, just "return $this" at the end of a mutator.

On the other hand, methods designed to be used like that should have 
strong return contracts, and throw exceptions themselves on error, so 
neither engine exceptions nor an extra operator would be necessary if 
the underlying library was written well.

I'm kind of on the fence as to whether this is the right solution to the 
problem.

-- 
Rowan Collins
[IMSoP]