Re: [scala] Option vs null

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim McBeath wrote:
| As a vehicle for helping me learn Scala, I have converted one of my
| Java programs over to Scala.  The Java code included a class with two
| methods overloading the same name, one with an optional File argument
| and the other with an optional String argument (representing a file
| name).  The Java methods looked something like this:
|
|     import java.io.File;
|     public class Test {
|         //f is optional, may be null
|         public void foo(String s, File f) { }
|
|         //name is optional may be null
|         public void foo(String s, String name) { }
|     }
|
| As part of the conversion to Scala, I wanted to use Option objects
| rather than using null to represent missing values.  After converting
| to Scala, the above code looked something like this:
|
|     import java.io.File
|     class Test {
|         |         def foo(s:String, fOpt:Option[File]):Unit = { }
|
|         def foo(s:String, nameOpt:Option[String]):Unit = { }
|     }
|
| However, the compiler gives me the following error message:
|
|     test.scala:6: error: double definition:
|     method foo:(String,Option[String])Unit and
|     method foo:(String,Option[java.io.File])Unit at line 4
|     have same type after erasure: (java.lang.String,Option)Unit
|
| Is there an elegant solution for this?  I could of course change the
| names so as not to use overloading, or add an argument to one or the
| other method to disambiguate.  I thought about trying to coalesce the
| two methods into one, but I don't think I can declare an
| "Option[String or File]" type, and changing it to Option[Any] would
| weaken type-checking at caller sites.

Personally, I'd delete the String function and write a String -> File implicit (if that is not to your liking, I'd abstract it in away such that it does).

|
| At the moment I have reverted the overloaded methods back to their
| original signature, accepting a nullable String or File rather than an
| Option, but I am hoping there is a better "Scala way" solution.
|
|
| There are a couple of small things that could be added to Scala
| to make it a little simpler to interface to legacy Java code that
| uses null as a marker for missing data.  In particular, it would be
| convenient to have a "getOrNull" method on Option values when calling
| into legacy Java code, and to have an easy way to create a None if
| the raw value returned by legacy Java code is null, or a Some if
| not null.

These two functions exists in Scalaz

http://projects.workingmouse.com/public/scalaz/artifacts/latest/scaladoc/scalaz/Maybe.html#toNull
http://projects.workingmouse.com/public/scalaz/artifacts/latest/scaladoc/scalaz/Option$object.html#onull(A)

|
|
| I was also a bit surprised to discover that Some(null) is legal.  I
| thought the whole purpose of Option was not to have null values
| floating around.  Perhaps there should also be a Some.notNull(x)
| constructor that would throw an exception if x==null.

This discussion has been had. The purpose of Option is not to have null floating around. It just solves that problem by consequence. Similarly, the purpose of a car is not to generate heat from its engine bay. Option is just an algebra like so many others.

|
| --
| Jim
|
|
|


- --
Tony Morris
http://tmorris.net/

Real-world problems are simply degenerate cases of pure mathematical problems.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIdEkUmnpgrYe6r60RAhqYAKDE5SukiFU/YDcDNpJkZ0BON4OxZgCgwYvp
oqPgjYQ7TtYbthDNQoTIThU=
=7ule
-----END PGP SIGNATURE-----