Scala stawia pierwszeństwo niejawnej konwersji na "naturalne" operacje ... Dlaczego? Czy to błąd? Czy robię coś złego?

Question

Ten prosty test, oczywiście, działa zgodnie z oczekiwaniami:

 
scala> var b = 2 
b: Int = 2 

scala> b += 1 

scala> b 
res3: Int = 3 

Teraz przynieść to w zakresie:

 
class A(var x: Int) { def +=(y:Int) { this.x += y } } 
implicit def int2A(i:Int) : A = new A(i)    

jestem definiowania nowej klasy i + = praca na nim, i wygodna niejawna konwersja dla tych czasów, kiedy chcę dodać wartość Int do A Int.

Nigdy się nie spodziewałem, że to wpłynie na sposób, w jaki zachowują się moje zwykłe operacje Int, kiedy klasa "A" wcale nie jest częścią wyrażenia.

Ale robi:

 
scala> var b:Int = 0 
b: Int = 0 

scala> b += 1 

scala> b 
res29: Int = 0 

scala> b += 2 

scala> b 
res31: Int = 0 

Co wydaje się być tutaj dzieje jest to, że b: int jest niejawnie konwertowane do klasy „A”, który nie jest związany z żadną zmienną, a następnie + = jest wywoływany na nim, odrzucając wyniki.

Scala wydaje się dawać wysoki priorytet niejawnej konwersji ponad naturalnym + = zachowaniem (magia kompilatora, a nie faktyczna metoda), która jest już zdefiniowana jako Ints. Zdrowy rozsądek jak również tło w języku C++ mówi mi, że implicite należy wywoływać tylko w ostateczności, gdy kompilacja w przeciwnym razie byłaby nieudana. To prowadzi do wielu pytań ...

• Dlaczego? Czy to błąd? Czy to projekt?
• Czy istnieje obejście (inne niż niewykorzystywanie "+ =" dla operacji "+ =" mojego DSL)?

Dzięki

Answer 1

Nawet pomimo wyjaśnienia Eastsun, wygląda na to, że jest to błąd i powinien wypróbować transformację b=b+1 przed próbą niejawnej konwersji dla +=.

Proszę zadać to pytanie na listę e-mailową użytkownika scala, wysyłając wiadomość e-mail na adres scala-user@listes.epfl.ch lub odwiedzając stronę internetową n4.nabble.com/Scala-User-f1934582.html. Jeśli jest to błąd, to tam zostanie zauważony i naprawiony.

Answer 2

Nie sądzę, że to błąd. W rzeczywistości Int ma tylko metodę "+", ale nie ma metody "+ =". b + = 1 przekształciłby się na b = b + 1 w czasie kompilacji, jeśli nie istnieje inna domena, która ma metodę "+ =".

Answer 3

od programowania w Scali, rozdział 17:

Kiedy piszesz + = b, a nie nie obsługuje metodę o nazwie + =, Scala postara interpretując je jako a = a + b .

Klasa Int nie zawiera metody +=. Jednak klasa A zapewnia metodę +=. Może to być przyczyną niejawnej konwersji z Int na A.

Answer 4

Scala wydaje się dawać większy priorytet ukrytą konwersji w naturalnym += już zdefiniowanego do Int s.

O której wersji Scali mówisz? Nie znam żadnej wersji, która ma metodę += na Int. Z pewnością żadna z nadal obsługiwanych wersji nie musi być starą wersją, która musi tam być.

A ponieważ nie ma += na Int, ale jesteś nazywając metodę += na Int, Scala stara się spełniać tego typu ograniczenie poprzez niejawna konwersja.

Answer 5

Jak zauważyli inni, Int nie może mieć + = "metody", ponieważ Int jest niezmienne. Zamiast tego, x + = 1 jest traktowane jako krótka forma dla x = x + 1, ale tylko wtedy, gdy nie ma metody o nazwie + =, która jest zdefiniowana na typie. Dlatego pierwszeństwo ma metoda rozstrzygania.

Biorąc pod uwagę, że Scala pozwala zdefiniować metody + =, a także pozwala na + = na zmiennych, czy moglibyśmy zmienić priorytet dwóch? To znaczy. spróbuj rozwinąć + = pierwszy i tylko wtedy, gdy to nie powiedzie się dla metody o nazwie + =?

Teoretycznie tak, ale twierdzę, że byłby on gorszy niż obecny system. Praktycznie nie. W bibliotece kolekcji Scali znajduje się wiele typów, które definiują zarówno metodę + dla nieinwazyjnego dodawania, jak i metodę + dla destrukcyjnego dodawania. Gdybyśmy włączony priorytet wokół następnie wywołanie jak

 
    myHashTable += elem 

rozwinie się do

 
    myHashTable = myHashTable + elem 

Tak byłoby skonstruować nowy hashtable i przypisać to z powrotem do zmiennej, zamiast po prostu aktualizowania elementu. To nie jest mądra rzecz ...