def takeBest(myLongClassName) ...
--
You received this message because you are subscribed to the Google Groups "scala-sips" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
implicit type xs: List[Int]
import com.example.{obj: MyCustomTypeIWillUseOftenInMyCode}
implicit type i: Int
def myMethod(obj: MyCustomTypeIWillUseOftenInMyCode, xs: List[Int], i: Int) = ...
def myMethod(obj, xs, i) = ...
val f = (i,xs) => xs(i)
<bikeshedding>I'd prefer flipping this on its head: rather than making the arguments typeless and name-mangling to get types, I'd make them nameless:
def takeBest(: LongClassName):// status quo
implicitly[LongClassName]// with shorthand
?[LongClassName]
Where the thing is implicit, and you only are allowed to have one variable of that type around. That restriction is not too bad, since if you have multiple variables of the same type you probably should give them separate names anyway.
The advantage of doing it this way is that we already have a known mechanism for going from Type => Term (implicits) which we could re-use, as opposed to making a whole new mechanism for going from termName => Type, and they both accomplish roughly the same thing.
This will also allow you to avoid assigning dummy names to implicits which you never use, e.g.
def doStuff(i: Int)(implicit ec: ExecutionContext) = ...
in such cases, the names given to implicits are completely meaningless, and forcing programmers to give things meaningless names is =<. If we could use:
def doStuff(i: Int)(implicit: ExecutionContext) = ...
Implicit typing would not reduce the readability, no much more if it is well used than using meaningful function names.
Indeed, if variable names are well choosed, then their type is obvious. In eclipse, you still have CTRL+F2 to open the type of a variable.
It might introduce more CPU cycles for compilation only if it is used. I bet it will be used more often if implemented. Of course, its implementation would require a lot of changes in the compiler, the incremental compilation, the parser, the IDE plugin. But this is why a SIP is written and I'm defending the worth of such addition. At least the compiled code will be the same, the same way that import statement and implicits are not present anymore at compile time. So binary compatibility is not an issue.
Another application? Look at this DSL definition:
implicit type s,t,u,v: String
class RichString(s) {
def add t = s + t
def diff t = if(s.size < t.size) ....
def pump u v = s"$u($s)*$v"
def search t = s.indexOf(t)
}
compared with the readability of the usual (and I omitted the return type because we are all "used" to this magic).
class RichString(s: String) {
def add(t: String) = s + t
def diff(t: String) = if(s.size < t.size) ....
def pump(u: String, v: String) = s"$u($s)*$v"
def search(t: String) = s.indexOf(t)
}
I will not have the time to implement a prototype for the next Scaladays because I have to help a master thesis student in his project. I assume that you expect an implementation, right?
I could do it if someone who knows the scala compiler well could help me to find the parts to change. Do you know anyone who could help me?
Best regards
Maybe I should split the SIP into two. The first part is indeed kindof magic - which I still promote. Type inference is also magic. For sure.
The thing is that it looks good.
Look at this DSL definition:
implicit type s,t,u,v: String
class RichString(s) {
def add t = s + t
def diff t = if(s.size < t.size) ....
def pump u v = s"$u($s)*$v"
def search t = s.indexOf(t)
}
class RichString(s: String) {type = Stringdef add(t) = s + tdef diff(t) = if (s.size < t.size) ...def pump(a,b) = s"$a($s)*$b"def search(template) = s indexOf template
}
--
--
--