0
class JavaRxObservable
class MyObservable extends JavaRxObservable

object MyObservable {
  implicit class ObservablePimp(o: JavaRxObservable) {
    def flatMapPimp: JavaRxObservable = ... 
  }
}

def api: JavaRxObservable = new MyObservable

api.flatMapPimp // is this possible without import statement ?

Note that it is not possible to create a companion object to third party type JavaRxObservable. And since my api method must return JavaRxObservable type because of its combinatory nature (MyObservable#map would return JavaRxObservable), it is a major drawback in API design because you are forcing people to read documentation that they gotta import stuff to use your api. Not even declaration in package object helps if it is meant to be API used by third parties.

lisak
  • 21,611
  • 40
  • 152
  • 243
  • You "gotta import stuff" to use *any* API. That's just life ... – Dima Dec 17 '14 at 12:30
  • Yeah, `import com.example.Foo` ... but not `import com.example.Foo; import com.example.Foo.ObservablePimp` - that's just hard life :-) – lisak Dec 17 '14 at 12:32
  • import com.example.Foo._ – Dima Dec 17 '14 at 14:19
  • That's even more awful – lisak Dec 17 '14 at 15:10
  • 1
    I disagree. I think, what's really awful is when things happen magically. Like, when a new method appears on a well-known standard library object,without even a hint at where it is defined or how to get rid of it. Implicits are bad enough in that respect ... but if they worked without even have to be imported into scope, that would be just crazy :) – Dima Dec 17 '14 at 15:14
  • You sound like you haven't seen those bunches of jira and github issues : "It doesn't work"; Closed : "You must import `com.example.whatever._`". I'm sick of these, its a recurring problem and import hell. If somebody is new to scala, it will just all be a magic to him, import statements doesn't make it less of a magic. They just prolong the agony of learning how it works. This freedom of declaring implicits all over, importing them everywhere is imho wrong, but that's another discussion:-) Imports should be used for overriding defaults not for using pimped classes or ad-hoc polymorphism – lisak Dec 17 '14 at 21:35
  • Import statements may not be making it less magic, but, at least, they give you a hint at where to start looking for the definitions of the "enhancer" methods that got magically attached to your objects. – Dima Dec 17 '14 at 22:12
  • I guess that people who use IDE have a different opinion than those who don't. – lisak Jan 27 '15 at 10:55
  • What does it have to do with IDE (I don't use one, so you might know something here that I just don't ;))? – Dima Jan 27 '15 at 13:54
  • I was reacting on your last message. IDE tells you exactly where the [definitions are located](https://confluence.jetbrains.com/display/IntelliJIDEA/Working+with+Scala+Implicit+Conversions) – lisak Jan 29 '15 at 12:14
  • well, yeah ... Call it a personal idiosyncrasy, but I despise source code that requires additional software to be *read*. You can't rely on IDE always being available to the reader of your code. They could be browsing github, or grepsource, or use some other way to navigate your source remotely. Also, IDE is no silver bullet anyway. Consider a function `def foo(bar: Int)(implicit context: SuperDuperContext)`, that's called somewhere like `foo(1)`. Can you tell what the `context` parameter is and where it comes from? Does IDE help? – Dima Jan 29 '15 at 14:38

0 Answers0