Re: [PHP-DEV] [RFC] Nullable Casting

[M. W. Moe]

Hello,

i) was intentional.

ii) Not our fault, we do not have this function in our code-base and won't
ever; we would not even dare 8).

Cheers!

On Mon, Apr 8, 2019 at 7:44 AM Dan Ackroyd  wrote:

> On Mon, 8 Apr 2019 at 04:21, M. W. Moe  wrote:
> >
> > Hello,
> >
> > looks like you are living in a pig stall; php would be benefit from type
> safety when explicitly required.
> >
> > Regards.
>
> Hi Moe,
>
> It seems you:
>
> i) accidentally hit reply, instead of reply all. This is an easy
> mistake to make.
>
> ii) Appear to be trying to compare me to a pig? I'm not sure that this
> is contributes to a productive discussion. Technical arguments are
> much better received than animal comparisons.
>
> cheers
> Dan
> Ack
>

Re: [PHP-DEV] [RFC] Nullable Casting

[Pedro Magalhães]

On Mon, Apr 8, 2019 at 6:05 AM David Rodrigues 
wrote:

> Current solution:
>
> $itemsPerPage = Input::get('itemsPerPage') ?: null;
> $itemsPerPage = $itemsPerPage !== null ? (int) $itemsPerPage : null;
>
> $paginator->setItemsPerPage($itemsPerPage); // OK
>
> With this new feature: just...
>
> $paginator->setItemsPerPage((?int) Input::get('itemsPerPage')); // OK
>
> Question: why just not check if $itemsPerPage is set like:
>
> $itemsPerPage = Input::get('itemsPerPage');
>
> if ($itemsPerPage) {
> $paginator->setItemsPerPage((int) $itemsPerPage); // OK
> }
>
> Answer: because in this example we could do that (although the new solution
> is much more practical). 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.
>

Hi!

I'm not a fan of the approach for a few reasons:
- First and foremost, we would introduce a cast where you can't be sure of
what you'll get back. I understand the use-case for when you want to pass
something to a nullable parameter, but if you think about this cast in
isolation, it hardly makes sense.
- Second, maybe this is particular to your example, but your are forcing
yourself to process something that the user didn't set. If your paginator
already has a sane default(15) in a property, just don't call its setter
when the user didn't ask you to. If you insist that you really want to save
LoC, just assume that 0 means "use the default" and you can use the cast in
all cases.

Regards,
Pedro

[PHP-DEV] Re: Optimize zend_string equality check with hash key

[Andrea Faulds]

Hi Benjamin,

Benjamin Coutu wrote:

   if (ZSTR_H(s1) && ZSTR_H(s1) != ZSTR_H(s2)) {
 return 0;
   }


Should that not be like this?:

if (ZSTR_H(s1) && ZSTR_H(s2) && ZSTR_H(s1) != ZSTR_H(s2)) {

It would be possible the other string also has no hash value.

Otherwise this sounds sensible to me, but it is also so obvious that I 
was assuming until now that PHP does it, so maybe someone else knows a 
reason why we don't? (Maybe it's just not worth the extra branches?)


Thanks,
Andrea

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Casting

[Claude Pache]

> Le 8 avr. 2019 à 07:05, David Rodrigues  a écrit :
> 
> And about "settype($variable, "?int")" it was requested on original mailing
> by Claude Pache.

PHP has several ways to perform casting:
1. (int) $foo
2. settype($foo, 'int');
3. intval($foo)

They are occasions where the programmer will prefer one method to the other. 
For example:
1. foo((int) $bar)
2. settype($someNonTrivial[$expr]['ession'], 'int');
3. array_map('intval', $foo)

The `intval($foo)` family of functions might be replaced by `function ($foo) { 
return (int) $foo; }` (or maybe soon by `fn($foo) => (int) $foo`), so that it 
might not be a necessity to double them with `intvalIfNotNull($foo)`, etc. 
functions (also, finding a good name is not evident). But as for `settype()`, 
it cannot be replaced by casting syntax in case the target type is not written 
literally in source code; so that we should continue to fully support it. (And 
see https://externals.io/message/103779#103805 
 for real world usages.)

—Claude

Re: [PHP-DEV] [RFC] Nullable Casting

[Claude Pache]

> Le 8 avr. 2019 à 12:24, Stephen Reay  a écrit :
> 
> if your target ’type’ is `?int` and you pass an empty string, wouldn’t you 
> expect to get `null` rather than `0` ? 


You should get the same value than you get in:

```php
declare(strict_types=0);

function foo(?int $x) {
return $x;
}

foo("");
```

BTW, this is an argument to the have nullable casting functionality in core, 
rather than leave each developer to craft their own solution. Because PHP does 
already such nullable castings in several occasions (typed parameters, typed 
return values, and soon typed class properties, when you are in strict_types=0 
mode), we should offer the programmers a built-in evident way to do the same 
type of casting, with the same semantics in occasion they want to do it 
manually. Otherwise, one developer will decide to map the empty string to null, 
the other to 0 and the third to NAN, and they get problems when they refactor 
the code in a way that a manual casting is replaced by an automatic implicit 
casting or vice versa, and the semantics differs on some cases.

—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Casting

[Dan Ackroyd]

On Mon, 8 Apr 2019 at 06:05, David Rodrigues  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

Re: [PHP-DEV] [RFC] Nullable Casting

[Dan Ackroyd]

On Mon, 8 Apr 2019 at 04:21, M. W. Moe  wrote:
>
> Hello,
>
> looks like you are living in a pig stall; php would be benefit from type 
> safety when explicitly required.
>
> Regards.

Hi Moe,

It seems you:

i) accidentally hit reply, instead of reply all. This is an easy
mistake to make.

ii) Appear to be trying to compare me to a pig? I'm not sure that this
is contributes to a productive discussion. Technical arguments are
much better received than animal comparisons.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Convert ext/xml to use an object instead of resource

[Nikita Popov]

On Thu, Mar 21, 2019 at 3:39 PM Nikita Popov  wrote:

> On Tue, Feb 12, 2019 at 4:00 PM Nikita Popov  wrote:
>
>> Hi internals,
>>
>> The ext/xml extension currently has GC issues, see
>> https://bugs.php.net/bug.php?id=76874. The tl;dr is that uses of
>> xml_parser will usually result in a cyclic structure, but resources do not
>> support cycle GC. This means that the user is required to take care of
>> breaking GC cycles manually, which is very unusual for PHP.
>>
>> I would like to port the xml extension from using a resources towards
>> using an object, which is fully GC integrated. This is implemented in
>> https://github.com/php/php-src/pull/3526.
>>
>> An XmlParser class is used instead of a resource. The class is final and
>> cannot be manually constructed. It is still used with the normal
>> xml_parser_* APIs. This is intended as an internal representation change,
>> not a conversion to OO APIs. The xml_parser_free() method becomes
>> effectively a no-op and may be deprecated in some future version.
>>
>> This change is intended for PHP 7.4. While it is technically BC breaking
>> (in that code that goes out of the way to use is_resource or similar may
>> break), but we've done a couple of these resource->object migration in
>> minor versions in the past (ref
>> https://wiki.php.net/rfc/operator_overloading_gmp and
>> https://wiki.php.net/rfc/hash-context.as-resource).
>>
>> Any thoughts?
>>
>> Regards,
>> Nikita
>>
>
> I'd like to move forward with this. Jakub requested this change to be
> postponed to 8.0 in
> https://github.com/php/php-src/pull/3526#issuecomment-469796632 to
> minimize BC issues. As 8.0 is close I'm okay with just doing that, this is
> not super urgent for me.
>
> Is there anything else that needs to be resolved here, or is this good to
> go for PHP 8.0?
>
> Nikita
>

As there haven't been further comments here, I've merged this change for
PHP 8 only.

Nikita

[PHP-DEV] Re: [RFC] Arrow functions / short closures

[Nikita Popov]

On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov  wrote:

> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob. It uses
> the syntax
>
> fn($x) => $x * $multiplier
>
> and implicit by-value variable binding. This example is roughly equivalent
> to:
>
> function($x) use($multiplier) { return $x * $multiplier; }
>
> The RFC contains a detailed discussion of syntax choices and binding modes.
>
> Regards,
> Nikita
>

Heads up: I plan to start voting on this RFC tomorrow if nothing new comes
up.

Most of the discussion was (as expected) about the choice of syntax.
Ultimately I think there are many reasonable choices we can make here, but
we should stick to a specific proposal for the purposes of the RFC vote.
None of the given arguments convinced me that some other syntax is
*strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a
matter of some choices being slightly better in one case and slightly worse
in another. My personal runner-up would be \($x, $y) => $x*$y, but I
suspect that there are some people who are more strongly biased against
"sigil salad" than I am...

Nikita

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Nikita Popov]

On Thu, Apr 4, 2019 at 4:15 PM CHU Zhaowei  wrote:

> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array Expression](
> https://wiki.php.net/rfc/spread_operator_for_array). The biggest change
> is I have dropped the support for string keys in v0.2 as suggested by Côme,
> to make the behavior of spread operator consistent. I have also added Q
> to explain the questions I received.
>

This looks reasonable to me. My only concern would be the "by-reference
passing" section of the RFC. The current proposal states that [...$arr]
will preserve references in $arr, which is not the behavior I would expect.

Is this choice for parity with the unpacking functionality in calls? In
that case I think it is important to understand that for argument unpacking
the handling of references is decided by the called function, not what is
in the array. If the function accepts an argument by-reference, then the
corresponding element in the array will be turned into a reference
(regardless of whether it was one before). Conversely, if the function
accepts an argument by-value, then the element from the array will be
passed by-value (regardless of whether it was a reference before). A
similar concept doesn't really exist for unpacking in arrays.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Nullable Casting

[Benjamin Morel]

>  if your target ’type’ is `?int` and you pass an empty string, wouldn’t
you expect to get `null` rather than `0` ?

I'd personally expect an `Error`, but this is not very much in line with
current casting semantics.

You have a point here, there is no clear answer for this edge case.

Maybe before nullable casting, should be discussed throwing errors when
attempting to cast a bad value, such as `(int) ""` ?
I think we're getting one step closer with the string to number comparison
RFC , which suggests
that `"" != "0"`.

Ben



On Mon, 8 Apr 2019 at 12:25, Stephen Reay  wrote:

>
> > On 8 Apr 2019, at 16:35, Benjamin Morel 
> wrote:
> >
> >> register_cast_function('?int', 'castToIntOrNull');
> >
> > I would quite oppose such a generic implementation, as it might have
> > unexpected consequences in other parts of the codebase : it's a global
> > configuration set at runtime.
> >
> > I quite like the idea of nullable casting though, as I've come across a
> few
> > cases myself where this would have been useful and would have made the
> code
> > more concise/readable.
> >
> > Ben
> >
> > On Mon, 8 Apr 2019 at 04:55, Dan Ackroyd  wrote:
> >
> >> 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 ths function getIntOrNull() in
> >> your code-base? To help me understand where this would be useful,
> >> could you provide some 'real-world' code where this would be useful?
> >>
> >> By the way, this RFC is a special case of something that could be far
> >> more generic. If it was possible to register callbacks to be used when
> >> casting, people could do something like this:
> >>
> >> function castToIntOrNull($value)
> >> {
> >>if ($value === null) {
> >>return null;
> >>}
> >>
> >>return (int)$int;
> >> }
> >>
> >> register_cast_function('?int', 'castToIntOrNull');
> >>
> >> $x = (?int)getIntOrNull();
> >>
> >>
> >>> Additionally, it was requested on the mailing list to consider adding
> >>> support of nullable types to the settype() function,
> >>> e.g. settype($variable, "?int")
> >>
> >> Someone probably needs to make an argument for it to be in core,
> >> rather than just saying that it's something that could be done.
> >>
> >> cheers
> >> Dan
> >> Ack
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
> I’ve come across this pattern (string variable contains a number or
> nothing) myself, but it also then makes me think - if your target ’type’ is
> `?int` and you pass an empty string, wouldn’t you expect to get `null`
> rather than `0` ?
>
>
>
>
>

Re: [PHP-DEV] [RFC] Nullable Casting

[Stephen Reay]

> On 8 Apr 2019, at 16:35, Benjamin Morel  wrote:
> 
>> register_cast_function('?int', 'castToIntOrNull');
> 
> I would quite oppose such a generic implementation, as it might have
> unexpected consequences in other parts of the codebase : it's a global
> configuration set at runtime.
> 
> I quite like the idea of nullable casting though, as I've come across a few
> cases myself where this would have been useful and would have made the code
> more concise/readable.
> 
> Ben
> 
> On Mon, 8 Apr 2019 at 04:55, Dan Ackroyd  wrote:
> 
>> 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 ths function getIntOrNull() in
>> your code-base? To help me understand where this would be useful,
>> could you provide some 'real-world' code where this would be useful?
>> 
>> By the way, this RFC is a special case of something that could be far
>> more generic. If it was possible to register callbacks to be used when
>> casting, people could do something like this:
>> 
>> function castToIntOrNull($value)
>> {
>>if ($value === null) {
>>return null;
>>}
>> 
>>return (int)$int;
>> }
>> 
>> register_cast_function('?int', 'castToIntOrNull');
>> 
>> $x = (?int)getIntOrNull();
>> 
>> 
>>> Additionally, it was requested on the mailing list to consider adding
>>> support of nullable types to the settype() function,
>>> e.g. settype($variable, "?int")
>> 
>> Someone probably needs to make an argument for it to be in core,
>> rather than just saying that it's something that could be done.
>> 
>> cheers
>> Dan
>> Ack
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> 

I’ve come across this pattern (string variable contains a number or nothing) 
myself, but it also then makes me think - if your target ’type’ is `?int` and 
you pass an empty string, wouldn’t you expect to get `null` rather than `0` ? 





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.4 segfaults

[Matteo Beccati]

Hi Nikita,

On 08/04/2019 10:36, Nikita Popov wrote:
On Wed, Apr 3, 2019 at 2:48 PM Matteo Beccati > wrote:

I've identified two different kinds: one in zend_assign_to_variable and
the other one during shutdown. Here are the backtraces:

https://gist.github.com/mbeccati/da3e304cd1fcdeddc43ec35f4c5c224f


The zend_assign_to_variable issue should be fixed with 
https://github.com/php/php-src/commit/e86820eb568bf1badd94b6cc9fa958119cc06bb4. 
This issue was introduced by the typed properties implementation.


thanks! Yes, I can confirm the one in zend_assign_to_variable has been 
fixed.


Is there anything I can do to help track down the other one?


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Casting

[Benjamin Morel]

> register_cast_function('?int', 'castToIntOrNull');

I would quite oppose such a generic implementation, as it might have
unexpected consequences in other parts of the codebase : it's a global
configuration set at runtime.

I quite like the idea of nullable casting though, as I've come across a few
cases myself where this would have been useful and would have made the code
more concise/readable.

Ben

On Mon, 8 Apr 2019 at 04:55, Dan Ackroyd  wrote:

> 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 ths function getIntOrNull() in
> your code-base? To help me understand where this would be useful,
> could you provide some 'real-world' code where this would be useful?
>
> By the way, this RFC is a special case of something that could be far
> more generic. If it was possible to register callbacks to be used when
> casting, people could do something like this:
>
> function castToIntOrNull($value)
> {
> if ($value === null) {
> return null;
> }
>
> return (int)$int;
> }
>
> register_cast_function('?int', 'castToIntOrNull');
>
> $x = (?int)getIntOrNull();
>
>
> > Additionally, it was requested on the mailing list to consider adding
> > support of nullable types to the settype() function,
> > e.g. settype($variable, "?int")
>
> Someone probably needs to make an argument for it to be in core,
> rather than just saying that it's something that could be done.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP 7.4 segfaults

[Nikita Popov]

On Wed, Apr 3, 2019 at 2:48 PM Matteo Beccati  wrote:

> Hi dmitry, internals,
>
> As I wrote somewhere else, I've finally been able to find time to update
> the Bamboo instance I've been using during the past few years to run
> daily PHP builds, run their test suites and use them to run test suites
> of few popular open source projects as I've been doing since phpng.
>
> The Revive Adserver test suite has currently a few failures with 7.4
> that I need to look into, but some of them are in fact caused by
> segmentation faults in PHP, possibly by its legacy syntax usage:
>
> https://revive.beccati.com/bamboo/browse/REV-LP-P74M-1801
>
> I've identified two different kinds: one in zend_assign_to_variable and
> the other one during shutdown. Here are the backtraces:
>
> https://gist.github.com/mbeccati/da3e304cd1fcdeddc43ec35f4c5c224f
>
> I can provide more info on how to run the test suite or grant ssh access
> to the box if anyone is interested in digging deeper.
>

Hi Matteo,

The zend_assign_to_variable issue should be fixed with
https://github.com/php/php-src/commit/e86820eb568bf1badd94b6cc9fa958119cc06bb4.
This issue was introduced by the typed properties implementation.

Nikita

Re: [PHP-DEV] Allow number_format() have three args

[Nikita Popov]

On Mon, Apr 8, 2019 at 9:51 AM David Rodrigues 
wrote:

> Currently number_format() could accept one, two or four args. If three args
> is passed then you will receive "wrong parameter count for number_format()"
> error (ArgumentCountError).
>
> It have four parameters: float $number, int $decimals, string $dec_point
> and string $thousands_sep.
>
> * If one arg is passed, then $decimals = 0 and $thousands_sep = ",".
> * If two args is passed, then $dec_point = "." and $thousands_sep = ",".
> * If four args is passed, then it will respect given args;
>
> There some cases where we just don't need a $thousands_sep, so I suggest to
> accept three args with $thousands_sep = '' (and not a comma).
>
> It will works fine for the doc (
> https://www.php.net/manual/en/function.number-format.php) example:
>
> // english notation without thousands separator
> $english_format_number = number_format($number, 2, '.', ''); // Currently
> $english_format_number = number_format($number, 2, '.'); // After
> // 1234.57 (same result)
>
> The fourth parameter will change "the behavior" if compared with the
> another original cases, but it will happen because there is no reason to
> use three args if you pretends to keep the comma as fourth arg once that
> normally you will use or "." or "," as decimal separator.
>
> * If you pretends to use dot + comma, just use two args;
> * If you pretends to use comma + dot, just use four args;
> * If you pretends to use dot + nothing, use three args;
> * If you pretends to use comma + nothing, use three args


This seems very confusing. Despite the somewhat convoluted description in
the docs, the way the function currently works is with the

   number_format(float $number, int $decimals = 0, string $dec_point = ".",
string $thousands_sep = ",")

signature and all defaults behaving as usual, plus an explicit check to
prohibit three arguments.

I think it would make sense to allow three arguments to make this function
behave more normally, but in this case "," should stay the default of the
thousands separator. Changing a default value based on the number of
arguments passed would be a major WTF moment, imho. I don't think think the
confusion is worth saving an "" argument.

Regards,
Nikita

[PHP-DEV] Allow number_format() have three args

[David Rodrigues]

Currently number_format() could accept one, two or four args. If three args
is passed then you will receive "wrong parameter count for number_format()"
error (ArgumentCountError).

It have four parameters: float $number, int $decimals, string $dec_point
and string $thousands_sep.

* If one arg is passed, then $decimals = 0 and $thousands_sep = ",".
* If two args is passed, then $dec_point = "." and $thousands_sep = ",".
* If four args is passed, then it will respect given args;

There some cases where we just don't need a $thousands_sep, so I suggest to
accept three args with $thousands_sep = '' (and not a comma).

It will works fine for the doc (
https://www.php.net/manual/en/function.number-format.php) example:

// english notation without thousands separator
$english_format_number = number_format($number, 2, '.', ''); // Currently
$english_format_number = number_format($number, 2, '.'); // After
// 1234.57 (same result)

The fourth parameter will change "the behavior" if compared with the
another original cases, but it will happen because there is no reason to
use three args if you pretends to keep the comma as fourth arg once that
normally you will use or "." or "," as decimal separator.

* If you pretends to use dot + comma, just use two args;
* If you pretends to use comma + dot, just use four args;
* If you pretends to use dot + nothing, use three args;
* If you pretends to use comma + nothing, use three args;

-- 
David Rodrigues