there's something wrong with the == and coercion in the if() statement in any language.
making the switch in if() be a boolean only pushes the problem off to the programmer, who will often choose the wrong function or expression to do the conversion
PHP's rules, like Perl, does what the programmer wants a high fraction of the time. Except when they don't.
For instance, 0 == false isn't too crazy, it's like C. But automatic coercion of string values to ints makes "0" == false which is sometimes what you want and sometimes not.
Practically this burns people in form validation code because often you want to test if a field is an empty string and if you do the obvious thing you can end up kicking out "0".
When I write PHP I have my own "PHP on nails" library that has functions that smooth out most of the things that are wrong with the language, and one of them is a comparison operator that is somewhere between "==" and "===" that most frequently does what you want it to do.
in statically typed languages like Java, C#, Scala and C++ people are always screwing this up
most languages have some screwed-uppedness about collections, both intrinsic to the language and that gets introduced by people who make APIs that aren't well designed. for instance, arrays and Lists are often not quite perfectly uniform (and it's often a thoughtless arbitrary choice if people decide to return you one or the other) Scala introduces it's own collections that provide more confusion when you're working with Java. The .NET framework has a great implementation of generics (makes Java and Scala look like a joke) but there are still many legacy APIs in the .NET framework that use non-generic collections.
One result is that it's not always obvious what the right way to test for "empty" is. One of the worst of them is that pretty frequently APIs will give you a null when they ought to be sending you an empty collection, so you need to check for null.
Either the types that are returned are scala collections, or they're java collections. If you want to treat java collections like scala collections you can always `import JavaConversions._` and huzzah, shallow conversions and collection uniformity.
Finally, if something has the possibility of being null, you can use the option construct, e.g.
if (Option(someListThatMightBeNull).getOrElse(List()).isEmpty) { ... }
Or more likely:
Option(someListThatMightBeNull) match {
case Some(list) => // do something...
case None => // do something else...
}
More than likely if you're dealing with scala libs, things that can be "null" are returning options anyway.
Option[X] is a crock. It's forcing you to write same bulky if-statements that you need to write for null checks.
I want something like NOT NULL in SQL. Can't static typing make it completely impossible that I'll get a null in a situation where it should be completely impossible?
For instance if something is typed as a collection, I'd like to never see null, I'd rather always get an empty collection. If I have to test for None, I'm just adding more bulky code where errors can hide, particularly when the type inference system in Scala is always doing strange things behind my back.
In my mind, automatic conversions make the problem worse in Scala, not better. Code "just works" for the programmer in certain situations no matter how inconsistent people are in the types they use.
The trouble I see is that Scala programmers seem to be pretty random if they're going return an Array, a java.util.List or a scala.util.List. This is really a pain in the ass when I'm trying to access some Scala objects from Java and I don't have automatic conversion available. I'm also sure that these different choices have all kinds of effects when you consider inheritance, variance, type inference and all that. It adds to the problem of spooky action at a distance in Scala.
You have never looked more than 5 seconds at Scala, right?
Option[X] is only a crock if you haven't understood it.
Stop thinking of it as a "null check", start as thinking of it as a collection which can either hold 0 or 1 elements and then you are on the right track.
null in Scala mostly exists for Java compatibility.
Re: Collections ... you haven't looked even _once_ at it. All collections return an empty collection or None, based on the operation. There are maybe 2 methods in the whole Scala standard library which return null, and both are _not_ in the collection framework.
This is so unbelievable misinformed... I can't believe it you have no problem showing this level of ignorance publicly.
"type inference system in Scala is always doing strange things behind my back" ... Example please.
"Automatic conversions" WTF?
"The trouble I see [...]" this is so much pure bullshit.
http://ca.php.net/empty
-----
The following things are considered to be empty:
- "" (an empty string)
- [...]
--> "0" (0 as a string) <--
- [...]
- var $var; (a variable declared, but without a value in a class)
-----
Why the heck is "0" considered empty?