Объясните странное поведение компилятора Scala

Question

Я работаю со Scala 2.9.0.1 в Eclipse.

У меня есть иерархия классов / признаков Scala, что-то вроде:

A.scala: trait A
B.scala: trait B extends A
C.scala: trait C extends B

кроме более сложных; слишком велик для публикации в качестве примера.

Итак, C косвенно зависит от A, но A ничего не знает о C.

Теперь, если я меняю А, я везде получаю ошибку, поэтому я продолжаю свой путь. Когда я наконец исправил последнюю ошибку в C, компилятор неожиданно сказал мне, что A не может быть скомпилирован. Поскольку A никак не зависит от C, это не имеет никакого логического смысла. На самом деле я бы сказал, что это ошибка компилятора. Это случалось со мной несколько раз, и это очень расстраивает, потому что это означает, что мне нужно снова изменить A и снова изменить всю иерархию классов.

Есть ли способ заставить компилятор Scala (в Eclipse) дать мне надежный результат? Я единственный, кто получает такое поведение?

Answer 1

Я также заметил, что программа Scala может иметь «иерархию» ошибок, при которой некоторые ошибки компиляции не выявляются, пока другие не будут исправлены. Это не обязательно ошибка компилятора ( Другие говорят, что это, вероятно, ошибка со старым компоновщиком Scala IDE, который был исправлен в trunk .)

Одна стратегиячтобы сделать изменения постепенно:

1. Сделайте копию trait A и назовите ее trait A2.
2. Внесите необходимые изменения в A2, исправляя все ошибки компиляции, которые показываютвверх.Это просто, поскольку от A2 пока ничего не зависит.
3. Повторите для B2, C2 и т. Д.

Как только все заработает, замените исходные черты намодифицированные.Управление ревизиями (я использую git) может быть очень полезным в этом процессе.

Другая общая тактика, которую я считаю полезной, состоит в том, чтобы разделить дизайн на два этапа:

1. ПервыйЯ кодирую только типы, оставляя все тела метода пустыми.Гораздо проще исправлять ошибки типов, прежде чем на пути появится какой-либо реальный код.

2. Когда типы согласованы, я могу заполнять определения методов независимо, не беспокоясь о сложных ошибках компиляции.