On 04/14/2016 07:33 PM, Tom Worster wrote:
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
I have to agree with Tom. if foo(bar(), $val) could die because bar()
may return NULL, that's not an indication that foo() needs to accept
NULL. It's a sign that bar() should not be returning it in the first
place. :-)
I am highly, highly sceptical about nullable parameters or returns, and
frankly would rather they were not included in the language. By nature
they undermine type safety. At best, they indicate to all callers
"*every* time you call this function, you MUST put is_null() around it
or your program may fail randomly." While that's better to know
explicitly than not (which is the case for any untyped return, aka any
PHP code pre-7.0), it would be better still to, well, not have to worry
about that billion dollar mistake[1] cropping up in my code.
In a sense, if we really must allow for value-or-null (which I consider
a code smell in the 98% case) I'd prefer if it was ONLY available via
union types: That is, Something|null. That's longer and clumsier to
type, and harder to read. Which it should be. (Static casts in C++ have
a fugly syntax, which has been defended by the language designers on the
grounds that static casts are fugly, so the syntax for them should be as
well to remind you to stop doing it. There is a fair amount of validity
to that argument on affordance grounds, at least within C++.) Using an
easy short hand notation for something that is inherently a code smell
when you're already typing your code only serves to encourage something
we should be training people out of in the first place.
Unless you like having is_null() scattered around your code in a hundred
places... I don't. :-)
[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
