On 4/14/16, 5:46 PM, "Levi Morrison" <morrison.l...@gmail.com on behalf of le...@php.net> wrote:
>Having a separate method instead of `foo(null, "value")` makes it >difficult to use for the result of a function. I suspect that might be a good thing:) I don't know for sure but the possibility exists. >Assume `bar()` returns >`Bar | Null`; this would no longer work if they were separated: > > foo(bar(), "value") > >Functions are often composed so if something is the output of one >function it will likely be the input to another. Thus if returning >optionally null values is important to you so should optionally null >parameters. This was a chin-scratcher for me. On one hand, I see what you mean. On the other I couldn't think of an example from my experience (which I admit is very narrow -- I live a sheltered life) of such a bar() that I would feed straight foo(). The semantic convention for Something or null return, as I see it, is when bar() returns null, it is saying "I got nothing". What kind of foo() does the same thing to nothing at all as it does to a Something object? This is where I got stuck. Say I was doing the composition instead via chaining. Something::bar()->foo("value") is nonsense if bar() could return null. This suggests to me that the other composition might not be wise. *Either* bar() should not be returning Something or null (maybe it should instead return some other type that can represent all the possible returns) *or* we shouldn't try to compose like this and should test for the Somethingness of bar()'s return before apply ->foo("value") or foo(…, "value") to it. Or maybe this API needs an even more fundamental redesign. So, from my perspective, this might be an example of the limitation nudging us to think harder about the design. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php