Capire perché "pimp my library" è stata definita in questo modo in Scala

Question

Se voglio aggiungere un metodo a una classe in Scala, ho bisogno di fare qualcosa di simile:

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

Poi f.newMethod si tradurrà nella creazione di RichFoo e chiama il suo metodo.

sto cercando di capire il motivo per cui non è stato definito in modo simile a Ruby:

override class Foo { 
    def newMethod = bar 
} 

Il compilatore può guardare questa definizione, e creare una classe FooOverride con metodo newMethod statico che riceve un parametro di tipo Foo e chiama il suo metodo bar. Questo è il modo in cui Scala implementa i tratti. Devo ancora importare il pacchetto che contiene l'override di Foo per usarlo.

Sembra implicare meno digitazione, non richiede di inventare nomi e prestazioni migliori (non chiamare un metodo e creare un oggetto). Qualunque cosa il metodo di conversione implicito può fare all'interno del metodo aggiuntivo.

Sono sicuro di aver perso qualcosa e vorrei avere un'idea di cosa.

Answer 1

Ci sono altri usi per le conversioni implicite diverse da solo l'idioma "pimp my library", quindi non è davvero un caso di "perché non hanno fatto questo invece?", ma "perché non lo hanno fatto anche loro?". Certamente, non vedo alcun motivo per cui una sintassi dei metodi di estensione non possa essere aggiunta come suggerisci e probabilmente sarebbe un po 'più pulita, ma non c'è bisogno di farla, visto che il linguaggio supporta già un modo per ottenere lo stesso effetto .

Aggiornamento Ottobre 2011:

C'è una nuova proposta di aggiungere lo zucchero sintassi per questo caso d'uso: http://scala.github.com/sips/pending/implicit-classes.html

Answer 2

Come si impedisce a tale metodo di accedere all'ambito senza richiedere un'importazione esplicita e dandogli un nome? In effetti, come può un programma sapere quali metodi sono stati aggiunti senza farlo?

Quando si utilizzano tre diverse librerie, due delle quali aggiungono metodi al terzo in un modo incompatibile, come si potrebbe aggirare questo senza avere impliciti sotto controllo?

A parte ciò, non è possibile ottenere prestazioni migliori, poiché la JVM non consente di modificare una classe esistente. Nella migliore delle ipotesi, potresti ottenere il vantaggio di non dover inventare un nome e dover digitare meno a costo di non essere in grado di controllare ciò che viene fatto.

Come nota finale, se si vuole insomma, si può fare:

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