3 ms·
I don't understand what you mean when you say they went all-in on DSLs with implicits. I far more often use implicits for integrating Java libraries or paperin
by jfager 16y ago
I don't understand what you mean when you say they went all-in on DSLs with implicits. I far more often use implicits for integrating Java libraries or papering over clunky apis than for putting together DSLs.
- Nycto 16y agoJust take a look at how specs [1] works: "Some element" should { "behave in some way" in { // ... } } According to this, the String type has a "should" method and an "in" method, but it really doesn't. Instead, there is an implicit conversion from a string to another type that actually has those methods. They idea here is to make the DSLs more fluent by removing the need to worry about complex type interactions while designing the interface. It lets the users use the pre-existing types they're already familiar with. [1] http://code.google.com/p/specs/ http://code.google.com/p/specs/
- fizx 16y agoThese DSLs in Scala can be awful. I mean: val ivySvn = "ivysvn" % "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar" Oh, but if you use a different maven convention, just double up the first percent sign: val ivySvn = "ivysvn" %% "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar" Readable, yes; intuitive, no.
- jfager 16y agoImplicits are obviously useful for DSLs, I'm not disputing that. My point is that they're obviously useful for other things as well, and so it doesn't make sense to say their inclusion in the language is a sign that the designers are going "all in" for DSLs - that designation would seem to be reserved for features like macros or parser combinators.