Comment by justthistime_
11 years ago
case class Fruit(name: String, variants: Set[String])
val fruitJson =
Json.parse(
"""{
"name": "apple",
"variants": ["cox", "braeburn"]
}""")
val fruit = fruitJson.as[Fruit]
Doesn't seem to be too painful to me.
I agree that F# is syntactically closer to ML (though Scala is closer to ML with its module system which F# gave up completely).
In this base case, no, it isn't too painful. But once you get to larger and more complicated structures, F#'s type provider system can be a tangible timesaver. Especially if you're doing exploratory programming.
TBH, I think the JSON example might underrate things a bit anyway. Where type providers really start to feel impressive is when you get to tricks like being able to noodle around inside undocumented (or poorly documented) COM interfaces with the help of CodeSense, or getting red squigglies in your editor (and compile time errors) when there's a problem with an SQL query.
F# isn't all roses, of course. I really wish it had typeclasses, and discriminated unions are less powerful than Scala's case classes in some tangible ways. But from a purely pragmatic perspective, my (almost certainly biased) sense is that I can usually Get Things Done™ with less ceremony in F#, and type providers are a shining example of that pragmatism.
Well, then I think JSON is a petty bad example, because pretty much no service provides some schema-like specification of their protocol in JSON.
If there is one thing I learned using type providers it is that maintaining your own "description"–be it as sample data or a schema file–loses most benefits of using type providers in the first case.
On the other hand, want a type provider for X in Scala? Just write it.
Stuff is still moving around because Scala devs want to get the meta APIs right first, but if adapting things from time to time is not an issue, then go ahead.
Tell me what happens with that technique when your json has > 22 keys. ;)
(Edit) this is apparently working in the latest scala 2.11 But it killed my adoption of scala for real work early on. https://issues.scala-lang.org/browse/SI-7099
It works without issues.
I never have seen a use-case where this would have been an issue. Sure, it "looks" unfortunate, but there is only so much you can do when running on a completely uncooperative runtime.
If devs need a typed representation of unlimited length, they provide a HList and move on.
Such a representation will replace the length-limited tuples in a future version of Scala.