On: I Like PHP

[mbrzuzy]

Is PHP that much worse where it's worth it to jump onto the ruby ship?

I'm just starting to code one of my current projects, but in PHP. Should I consider ruby instead?

[adambard → mbrzuzy]

Here is some PHP code:

$x = "0"; if(!$x){ echo "0 is false"; }

If you understand why it's crazy that PHP prints "0 is false" when you execute that, you're probably better off jumping ship now. If you don't, you'll probably appreciate the low barrier to entry for PHP more than any benefit you'd gain.

[NathanKP → adambard]

I understand why it prints zero is false, and personally I feel that it makes perfect sense. Indeed I approve of it. The fact that strings can be evaluated as numbers is great for accepting input from GET or POST because it means that there is no need to worry about explicitly casting strings to numbers.

Of course, input type validation is still important, and if a variable input by the user is supposed to be numeric, that is why there is the is_numeric() function to validate the type of a variable.

But once I've used is_numeric() and know that the string is numeric why should I bother with an explicit strtoint call? I feel that this feature of PHP if used correctly takes away complexity and repetition related to converting strings to integers.

In a realistic project the framework for your app should have a layer between user input and your code anyway. At this layer it will be validating that input from the user is of the correct type anyway, and once that variable passes the is_numeric() test the layer can easily cast that input string to an int so that it is the right type for JSON encoded objects or any other output from PHP for other languages that needs to have specific types.

Once again, if PHP is used properly, with a decent code architecture this feature of PHP is not a problem.

[wtetzner → NathanKP]

Perl does the same thing with type coercion, and "0" in Perl is false. However, the thing that Perl does that PHP doesn't is have different operators for strings and numbers.

Don't get me wrong, I think conflating strings and numbers is a bad idea, but if you're going to conflate strings and numbers, then having separate operators is the right thing to do.

[NathanKP → wtetzner]

I am not very familiar with Perl. When you say different operators for strings and numbers are you referring to something similar to PHP's === operator for which "1"===true would be a false statement?

[chromatic → NathanKP]

Perl's numeric equivalence operator is ==, while its string equality operator is eq. Perl's operators are monomorphic that way.

[tingletech → NathanKP]

in perl

"==" returns true if the left argument is numerically equal to the right argument.

"eq" returns true if the left argument is stringwise equal to the right argument.

see 'perldoc perlop' under the heading "Equality Operators"

[mbrzuzy → adambard]

I understand the standpoint of people thinking it's crazy. But javascript does the same thing, does it not?

I thought this is what the triple equals is for?

[reinhardt → mbrzuzy]

Yes Javascript does it too, and it's considered one of its top warts for the same reason. The tl;dr version is: always use triple equals, never double.

[adambard → adambard]

Actually, here's a more insane version:

  $x = 0;

  if(!empty($x)){

    echo '"0" is empty';

  }

[pornel → adambard]

empty() is an alias for 'isset($x) && $x', so this example is semantically identical to the previous one (since $x is always set). PHP doesn't have any special concept of "emptyness" to check for.