Understanding why “pimp my library” was defined th

问题:

If I want to add a method to a class in Scala, I need to do something like:

class RichFoo(f: Foo) {
  def newMethod = f.bar()
}
object RichFoo {
  implicit def foo2Rich(f: Foo) = new RichFoo(f)
}

Then f.newMethod will result in creation of RichFoo instance and call its method.

I'm trying to understand why it was not defined similarly to Ruby:

override class Foo {
  def newMethod = bar
}

The compiler can look at this definition, and create a FooOverride class with static method newMethod that gets a parameter of type Foo and calls its bar method. This is how Scala implements traits. I still need to import the package containing the Foo override to use it.

It seems to involve less typing, doesn't require me to invent names, and has better performance (not calling a method and creating an object). Anything the implicit conversion method does can be done inside the additional method.

I'm sure I've missed something and would like to get an insight into what.

回答1:

There are other uses for implicit conversions other than just the "pimp my library" idiom, so it's not really a case of "why didn't they do this instead?", but "why didn't they do this as well?". Certainly, I can see no reason why an extension methods syntax couldn't be added as you suggest, and it would probably be somewhat cleaner, but there's not much pressing need for it given that the language already supports a way of achieving the same effect.

Update October 2011:

There's a new proposal to add syntax sugar for this use case: http://scala.github.com/sips/pending/implicit-classes.html

回答2:

How do you prevent that method from entering scope without requiring explicit importing and giving it a name? In fact, how can a program know what methods were added without doing so?

When you use three different libraries, two of which add methods to the third in an incompatible way, how would you get around that without having implicits under control?

Aside from that, better performance is not possible, as JVM doesn't allow one to change an existing class. At best, you could gain the benefit of not having to invent a name and having to type less at the cost of not being able to control what is being done.

As a final note, if you want short, you can do:

implicit def fooBar(f: Foo) = new { def newMethod = bar }