On Thu, Oct 24, 2019 at 8:54 PM Mike Schinkel <m...@newclarity.net> wrote:
> On Oct 24, 2019, at 6:49 PM, Ken Stanley <doh...@gmail.com> wrote:
> I would be keen to see the more expressive techniques that retain the
> succinctness of having a not-null coalescing operator.
>
>
>
> When I read your first example, I immediately thought I would handle your
> example in this way:
>
> $user->setFName( $_SERVER[ 'fname' ] ?? null );
>
> $user->setLName( $_SERVER[ 'lname' ] ?? null );
>
> $user->setMName( $_SERVER[ 'mname' ] ?? null );
>
> $user->setPhone( $_SERVER[ 'phone' ] ?? null );
>
> $user->setEmail( $_SERVER[ 'email' ] ?? null );
>
>
> Admittedly it does not require the functionality of your proposed
> operator, and it delegates the null handling to the set*() methods, but it
> is more succinct and does not require duplicating `$_SERVER[ '*' ]`, so
> it would be a winner for me.
>
>
The problem here is that null values may or may not be valid inputs for the
setters. Assuming for one moment that the setters do allow null, what does
that mean for the underlying model? Is null to mean that it’s under? Or is
null just another possible value?
Using !?? to only call a setter if there is a non-null value is very
important in many circumstances - my original example was to illustrate a
succinct way to implement a REST PATCH HTTP request, where only fields with
values get updated - in other words, you don’t want to set other fields to
null because you want to retain their original values; not overwrite them.
Overwriting values with null is a valid use case, but not for this operator
(not necessarily).
Null means nothing, no value, or better: not answered. This is distinctly
different than ‘’, false, or 0. Those are explicit responses to a question.
Null Just means no data.
> I also do not mind putting more effort into writing functions if it means
> less effort required to call the functions. But maybe that is just me?
>
>
But if you don’t have to, then why would you? I’m all for clarity and
expressiveness. But I’m also for simplicity and being as succinct as
practically possible.
> Your 2nd example was more compelling for me, but Sara's nullsafe calls RFC
> uses a syntax that is more clear and obvious to me.
>
>
I am a Symfony developer, and as such I like to utilize annotations (bear
with me). They have a ParamConverter annotation that can automatically look
up an entity based on the type hint given to a controller action.
If the parameter is null able, I may need to add an if condition to look up
a sane default value when the parameter comes through as null. It would be
much more succinct (and less error prone) to be able to say something like
/**
* @ParamConverter(name=“application”, ...)
*/
public function myAction(Request $request, Application $application)
{
$user = $application->getUser() !?? $this->getUser();
// ... do something with user, without worrying about it being null.
}
> Is there a 3rd or 4th use-case you have that are unlike the first two?
>
>
I will let you know when I think of them. I totally understand how much
easier it is for others to conceptualize with good examples. I want to be
concise and relevant at the same time, and that’s actually pretty
difficult. :-)
> -Mike
>
>
>
> --
"Do not go gentle into that good night. Rage, rage against the dying of the
light." — Dylan Thomas
