August 2009 is a long time ago, when Groovy 1.6 was the current version. The month before, Groovy's creator published a blog saying if he'd known about Scala he would never have created Groovy. And during the following month, Alex Tkachman published his first blog outlining his plans for Groovy++, which was eventually duplicated as the static typing facility in Groovy 2.x.
> println company?.address?.street?.name
I haven't used the Codehaus/Apache edition of Groovy since version 1.8 when there had been plenty of mailing list discussions about enabling ?. functionality to ripple through all subsequent . after the first use of ?. so that:
println company?.address.street.name
would be behave the same. Was this much talked about functionality ever implemented?
Edit:
Looks like the Haskell Maybe monad described by Arguggi in the other thread goes even one better than that by not even requiring their equivalent of ?. in the path at all but instead the typing system infers whether to use . or ?. functionality from the type of each field (company, address, and street in the example). I remember a mailing list discussion in the early days of Groovy begun by its creator James Strachan about whether to use some new syntax to require an object to be assigned to a variable:
Object! ob= new Object() //can't be null
Object ob //can be null
Unfortunately, he was, er, replaced by the current management soon afterwards.
This seems pretty similar to the Haskell Maybe Monad.
"Learn You a Haskell for Great Good!" has an example[0]:
routine =
case Just (0,0) of
Nothing -> Nothing
Just start -> case landLeft 2 start of
Nothing -> Nothing
Just first -> case landRight 2 first of
Nothing -> Nothing
Just second -> landLeft 1 second
becomes (using some 'do' syntactic sugar):
routine = do
start <- return (0,0)
first <- landLeft 2
second <- landRight 2 first
landLeft 1 second
Checking for Nothing is taken care of 'automatically' and if any of start, first, second or (landLeft 1 second) are equal to Nothing routine is equal to Nothing too.
routine :: Int -> Maybe Int
routine n = Just n >>= (divisorFilter 3) >>= (divisorFilter 2) >>= (divisorFilter 5)
-- Supporting function
divisorFilter :: Int -> Int -> Maybe Int
divisorFilter d n
| n `mod` d == 0 = Just n
| otherwise = Nothing
-- Using do syntax
routine' :: Int -> Maybe Int
routine' n = do
first <- divisorFilter 3 n
second <- divisorFilter 2 first
divisorFilter 5 second
Which goes to show that what requires a 'new feature' in C# is just a freebie in Haskell, due to the powerful type system. See my other comment ITT for how to do this in a tighter way that is more like the C# syntax. (You just use the bind operator rather than wrapping it in a do)
This isn't really the same thing. Haskell (and Ocaml) make you deal with the null case, whereas C# just lets you propagate the nulls. Haskell's way is safer, c# is just handy syntax.
While I have some appreciation for the fact that Scala doesn't make its `Option` type special from a syntactic standpoint--it's a sum type, like any other--I think there's something to be said for the type union with syntactic support. `optionalData?.methodOption?.method` is much more succinct than Scala's `optionalData.flatMap(_.methodOption).map(_.method)`, or `for (data <- optionalData; result <- data.methodOption) yield result.method`. Scalaz seems to provide some more concise aliases for the monadic chain, but there's still nothing I know of that gives you exactly the method access within a monad quite like `?.`.
Scala encourages people to not use nulls everywhere, so adding syntactic sugar for a special case, which is not even idiomatic Scala doesn't sound like a good idea.
Option is not a "replacement" for null. Sometimes another type is more appropriate to replace a usage of a null in Java/C#, so making Option special would be counter-productive.
I wouldn't use null anywhere in my Scala code, unless I had to in order to interface with a Java library. I'm talking about sugar for working with Option.
Where would this sugar stop? At Either? At Try? At Validation?
The problem is that if you introduce the sugar only for Option, users will tend to use Option even in cases where other type constructors would be more appropriate.
The null coalescing operator is nice, but it can be overused. I recently saw some Swift code that was riddled with question marks everywhere, which()?.made?.the?.code?()?.very?.difficult?.to?().read.
I wonder if it would be useful to have some kind of block scope for null coalescing? (Alternatively, why can't the programmer just specify the root coalesce and have the compiler figure out the rest?)
Beyond that, I imagine the solution is to just bake null coalescing into the language somehow. Then maybe you'd want to have a block scope for non-null coalescing code.
19 comments
[ 2.6 ms ] story [ 99.5 ms ] threadThis is one of the things I really miss when going back to JS.
http://mrhaki.blogspot.dk/2009/08/groovy-goodness-safe-navig...
August 2009 is a long time ago, when Groovy 1.6 was the current version. The month before, Groovy's creator published a blog saying if he'd known about Scala he would never have created Groovy. And during the following month, Alex Tkachman published his first blog outlining his plans for Groovy++, which was eventually duplicated as the static typing facility in Groovy 2.x.
> println company?.address?.street?.name
I haven't used the Codehaus/Apache edition of Groovy since version 1.8 when there had been plenty of mailing list discussions about enabling ?. functionality to ripple through all subsequent . after the first use of ?. so that:
would be behave the same. Was this much talked about functionality ever implemented?Edit:
Looks like the Haskell Maybe monad described by Arguggi in the other thread goes even one better than that by not even requiring their equivalent of ?. in the path at all but instead the typing system infers whether to use . or ?. functionality from the type of each field (company, address, and street in the example). I remember a mailing list discussion in the early days of Groovy begun by its creator James Strachan about whether to use some new syntax to require an object to be assigned to a variable:
Unfortunately, he was, er, replaced by the current management soon afterwards."Learn You a Haskell for Great Good!" has an example[0]:
becomes (using some 'do' syntactic sugar): Checking for Nothing is taken care of 'automatically' and if any of start, first, second or (landLeft 1 second) are equal to Nothing routine is equal to Nothing too.[0] http://learnyouahaskell.com/a-fistful-of-monads#walk-the-lin...
Option is not a "replacement" for null. Sometimes another type is more appropriate to replace a usage of a null in Java/C#, so making Option special would be counter-productive.
The problem is that if you introduce the sugar only for Option, users will tend to use Option even in cases where other type constructors would be more appropriate.
Beyond that, I imagine the solution is to just bake null coalescing into the language somehow. Then maybe you'd want to have a block scope for non-null coalescing code.