Real world example:
class Paginator {
// If null, will use the default value (eg. 15), else, it will requires
an int.
public function setItemsPerPage(?int $itemsPerPage) { ... }
}
// Info that came from user input.
// It will be a string, and not a integer, like we need.
$itemsPerPage = I
On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier wrote:
>
> Hello internals,
>
> David and I would like to open the discussion on our joint RFC:
>
> https://wiki.php.net/rfc/nullable-casting
>
> Mainly, it would enable to use e.g. `(?int)$x` besides `(int)$x`.
>
I'm guessing you don't actually have t
On Sun, 7 Apr 2019 at 17:08, CHU Zhaowei wrote:
>
> It there anyone working on this?
I'm planning to. I've just been also thinking about arrays and nulls
with pre/post inc/decrement.
I'm guessing code that is 'intentionally' doing:
$foo = false;
$foo++;
and
$foo = [];
$foo++;
are going to be
On 07/04/2019 17:08, CHU Zhaowei wrote:
In addition, I'm thinking whether it's possible and necessary to add a global strict mode
(like "use strict" in js) in PHP 8 to deal with this kind of unexpected
surprise. I know we have declare(strict_types=1) but it only works for functions and it's
li
It there anyone working on this? If not, I'd like to prepare a RFC targeting
PHP 8 to address this issue.
In addition, I'm thinking whether it's possible and necessary to add a global
strict mode (like "use strict" in js) in PHP 8 to deal with this kind of
unexpected surprise. I know we have de
Thanks for bringing this new serialization method to PHP 7.4, Nikita!
It would be nice if we could make this reusable beyond serialization. There
> are two caveats that come to mind:
> (...)
> The __unserialize() method assumes an already constructed object on
> which __unserialize() can be called
On 07/04/2019 11:53, Morgan Breden wrote:
>In order to use named parameters, somebody needs to have declared
what those names are, and made them a stable API. If they're
automatically supported on existing functions, the author might not
intend them to be used, or even realise they can, so not
>In order to use named parameters, somebody needs to have declared what
those names are, and made them a stable API. If they're automatically
supported on existing functions, the author might not intend them to be
used, or even realise they can, so not keep them stable (I tend to think of
parameter
On 7 April 2019 06:00:53 BST, CHU Zhaowei wrote:
>The [named parameters](https://wiki.php.net/rfc/named_params) was
>proposed in 2013. Does the problems which stopped us before still exist
>in 2019? Since we all agree named parameter should be a better
>solution, why not take a look at it first?
I mean it’s easier than named parameters. I guess I replied to wrong thread,
but wanted to contrast “default” with JSON_DEFAULT_DEPTH. Accepting string in
integer parameter just creates mores issues. And please don’t use name
conflicts as argument for not adding something. It’s absurd to stop ad
10 matches
Mail list logo
