Zrozumieć dlaczego „pimp my biblioteki” został zdefiniowany w ten sposób w Scala

Question

Jeśli chcę dodać metodę do klasy w Scala, muszę zrobić coś takiego:

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

Następnie f.newMethod spowoduje utworzenie RichFoo wystąpienie i wywołaj jego metodę.

Próbuję zrozumieć, dlaczego to nie zostało zdefiniowane w sposób podobny do Ruby:

override class Foo { 
    def newMethod = bar 
} 

Kompilator może spojrzeć na tej definicji i utworzyć klasę FooOverride metodą statyczną newMethod który pobiera parametr typu Foo i nazywa swoją metodę prętową. W ten sposób Scala wdraża cechy. Nadal muszę zaimportować paczkę zawierającą nadpisanie Foo, aby z niej skorzystać.

Wydaje się, że wymaga mniej pisania, nie wymaga wymyślania nazw i ma lepszą wydajność (bez wywoływania metody i tworzenia obiektu). Wszystko, co niejawna metoda konwersji, można zrobić wewnątrz dodatkowej metody.

Jestem pewien, że coś przeoczyłem i chciałbym dowiedzieć się, co.

Answer 1

Istnieją inne zastosowania dla ukrytych konwersji innych niż tylko „pimp my bibliotekę” idiom, więc to naprawdę nie jest przypadek "dlaczego nie zrobili tego zamiast tego?", ale "dlaczego nie zrobili tego tak dobrze?". Z pewnością nie widzę powodu, dla którego składnia metod rozszerzenia nie mogłaby zostać dodana, jak sugerujesz, i prawdopodobnie byłaby nieco czystsza, ale nie ma zbyt dużej potrzeby, ponieważ język już obsługuje sposób osiągnięcia tego samego efektu. .

Aktualizacja październik 2011:

Jest nowa propozycja, aby dodać cukier składnię tego przypadku użycia: http://scala.github.com/sips/pending/implicit-classes.html

Answer 2

Jak zapobiec wprowadzaniu tej metody do zakresu bez konieczności wyraźnego importowania i nadawania jej nazwy? W rzeczywistości, w jaki sposób program może wiedzieć, jakie metody zostały dodane bez tego?

Kiedy używasz trzech różnych bibliotek, z których dwie dodają metody do trzeciej w sposób niekompatybilny, jak poradzisz sobie z tym bez implikowania pod kontrolą?

Poza tym lepsza wydajność nie jest możliwa, ponieważ JVM nie pozwala na zmianę istniejącej klasy. W najlepszym wypadku można uzyskać korzyść polegającą na tym, że nie trzeba wymyślać imienia i pisać go mniej kosztem braku możliwości kontrolowania tego, co się robi.

W końcowej nocie, jeśli chcesz krótki, można zrobić:

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