When I did the last major change to fix the Array to string issues I considered using preg_replace() since "preg_replace() returns an array if the subject parameter is an array, or a string otherwise."

Unfortunetly, It's not a straight forward change to swap preg_match() with preg_replace().

Your change fails the unit tests. Your change returns 0 in places where there is an expected integer list.

• data set "int_01"
• data set "integer"

Your regx patern change breaks the integer tests by returning a signed value when an unsigned value should be expected.

• data set "int_06"
• data set "int_07"
• data set "int_13"

your pattern does the following

/[^-+0-9]/ match a single character not present in the list below
-+ a single character in the list -+ literally
0-9 a single character in the range between 0 and 9

The original pattern did
/[-+]?[0-9]+/
[-+]? match a single character present in the list below
Quantifier: ? Between zero and one time, as many times as possible, giving back as needed [greedy]
-+ a single character in the list -+ literally
[0-9]+ match a single character present in the list below
Quantifier: + Between one and unlimited times, as many times as possible, giving back as needed [greedy]
0-9 a single character in the range between 0 and 9

IMO this is not the correct change.

Can we use PHP 5.2 + sanitization ?

$source = "  -123-+45test6aa<br/>Γεία789  ";

// Sanitize characters
$result = filter_var((string) $source , FILTER_SANITIZE_NUMBER_FLOAT);

// Get sign
$sign = $result[0]==='-' || $result[0]==='+' ? $result[0] : '';

// Prepend sign and remove + - at inner places, typecast final string to int
$result = (int) ($sign . str_replace(array('+','-'), '', $result));


echo "<pre>^^".$result."^^</pre>";
exit();

@photodude Ahh, I can see that unit tests are failing.

The data set "int_01" and "integer" failing because regex returns +-0123456789 and as we have type cast it to integer it results into 0.
But we can replace sign as @ggppdk suggested.

While data set "int_06", data set "int_07" and data set "int_13" should return signed value because for unsigned integer we have another case 'UINT'.

@hardiktailored,

besides removing sign,
my suggestion is about performance too

@ggppdk Agree, works for me.

@hardiktailored From reading your issue statement I'm not sure what the problem is. Can you explain in more depth why you think this change is necessary?

Filtering always comes down to design choices. Since we don't have direct statements from the filter API creation team we'll have to deduce from the unit tests what expected behavior is (i.e. what design choices were made).

• Case 1, mixed numbers in the string
  • example: "test123test321"
    • There are three common options for design choices here.
      • 1) first occurrence (which would return 123)
      • 2) last occurrence (which would return 321)
      • 3) all occurrences (which would return 123321)

What's the right choice for a broad-based general API? IMO (based on the unit tests here) first occurrence likely makes the most sense. We have no knowledge of the endpoint usage so we have to make assumptions about what the user input intent is. With first occurrence, we are assuming that all following numbers could be a duplicate copy or other bad input.

• Case 2, mixed numbers in the string with multiple signs
  • example: "t-shirts-+130"
    • There are four general options for design choices here.
      • 1) first occurrence (which would return -130)
      • 2) last occurrence (which would return +130)
      • 3) first occurrence proceeding a number (which would return -130)
      • 4) last occurrence proceeding a number (which would return +130)

What's the right choice for a broad-based general API? IMO (based on the unit tests here) last occurrence proceeding a number likely makes the most sense. We have no knowledge of the endpoint usage so we have to make assumptions about what the user input intent is. With last occurrence proceeding a number, we are assuming only the last sign directly proceeding a number is intended to be a sign input. (this is the case with data set int_06, int_07 and int_13 which all should return signed value... but what signed value?)

Sure we can change the current behavior of the filters, but is it the right design choice? Are we solving one issue but introducing other behavior issues that differ from the original API design. Does the change improve the API behavior for 3rd party developers, or does it just change the expected behavior?

For all of these reasons, I think a more in-depth explanation of what issue this is solving and why it is necessary to make this API change.

As this hasn't been updated in quite some time, without updates this PR will be closed as abandoned in a few weeks.

If this PR get no Response, it will be closed at 22th June 2017.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/11582

closed as stated above.