On Mon, 8 Apr 2019 at 06:05, David Rodrigues <[email protected]> wrote:
>
> Question: why just not check if $itemsPerPage is set like:
> ...
> Answer: because in this example we could do that (although the new solution
> is much more practical).
Well, I disagree on that. That code is perfectly fine to me, and
having more operators to understand and remember is harder than having
fewer operators to understand and remember.
Also, I have a suspicion that the reason why you think this might be
needed is that you're doing too much work outside `Input::get`. If you
made a separate function that for `Input::getInt` that did all the
work of casting the value to int when appropriate, you wouldn't have
to repeat all the work in the functions that are calling `Input::get`.
i.e. you're causing a lot of typing to be required to further process
the result of a function, when you should be making new function that
does more precisely what you want.
> In another case, I have a static factory method that depends of an ?int to be
> created, and I can't just skip it with an if() if user input is empty.
But please can you post the actual use-case you _need_ this for. Or
possibly update the RFC with that example. Currently, imo, the RFC is
just presenting an alternative syntax for something that is not 100%
needed.
I do kind of like the idea in the RFC, but I think it needs a better
argument for it.
cheers
Dan
Ack
btw, the code you posted as:
> $itemsPerPage = Input::get('itemsPerPage');
>
> if ($itemsPerPage) {
> $paginator->setItemsPerPage((int) $itemsPerPage); // OK
> }
isn't quite the same as what the RFC does, right? The code equivalent
for the RFC would be this I think:
$itemsPerPage = Input::get('itemsPerPage');
if ($itemsPerPage !== null) {
$itemsPerPage = (int)$itemsPerPage;
}
$paginator->setItemsPerPage($itemsPerPage);
which even avoids the magic/horribleness of having to understand what
PHP thinks is empty.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
