jsOpt macros potential addition

[fancellu]

You mentioned this in the TODO

Done it with

https://github.com/lihaoyi/sourcecode

e.g.

import sourcecode.Name

trait SCOptionSetter[T <: js.Object, B <: SCOptionBuilder[T, _]] extends JSOptionSetter[T,B]{
  protected def jsOpt(opt: Any)(implicit name: sourcecode.Name): B
}

abstract class SCOptionBuilder[T <: js.Object, B <: SCOptionBuilder[T, _]](copy:OptMap => B) extends JSOptionBuilder[T,B](copy){
  protected def jsOpt(opt:Any)(implicit name: sourcecode.Name):B = {
    copy(dict + (name.value -> opt))
  }
}

def maxHeight(v:Int)= jsOpt(v)

[jducoeur]

Huh. That's clever, and rather tempting. I'm probably not going to pick it up, for two reasons:

• A lot of people are dependency-phobic, and this library has been intentionally dependency-free.
• JSOptionBuilder is probably going to get deprecated soon, on the grounds that Scala.js 0.6.14 largely renders it unnecessary.

But I'm going to leave this open here, at least for the time being, so folks can see how to do it if they like. (And we might add it to the documentation for those who are using both libraries.)

[fancellu]

Agreed. Its not like its hard to add to own project, just pull in "sourcecode" and use the 2 subclasses.

I know about the new 0.6.14 stuff, but it still looks pretty ugly, especially in 2.11. The builder API is pretty, and now even easier to author with sourcecode.Name

[jducoeur]

I haven't tried the new stuff in practice yet, so I don't quite have a clear sense of the tradeoffs; my general intuition is that it's less boilerplate per-interface; slightly more per-entry-point; and more consistent with the rest of the Scala.js system. I'll at least be pointing it out as an alternative for folks to consider; I'll decide whether to formally deprecate JSOptionBuilder after I've tried the new stuff on a few APIs myself.