Q
Size: a a a
2021 June 16
DP
в общем, это хороший способ проконтролировать, что ты все, что надо, имплементировал
RS
так оно же и так проконтролируется там где оно надо?
RS
или мы имеем ввиду декларативное описание самому себе того что мы хотим реализовать?
DP
возможны варианты. например, там приведение где-то, и оно проконтролируется только в рантайме.
а еще смешной, но плюс: если ты так сделаешь - goland предложит тебе создать недостающие сигнатуры. не сделаешь - может и не предложить
а еще смешной, но плюс: если ты так сделаешь - goland предложит тебе создать недостающие сигнатуры. не сделаешь - может и не предложить
RS
я так понимаю - у нас до сих пор нет CI тулзы, которая проконтролирует, не поломали-ли мы обратную совместимость пакета относительно последнего git tag'а?
ВС
А как это предлагается делать?
DP
вопрос не ясен
DP
мне кажется - это юнит-тесты
с
видимо брать старый код, как-то определять, что он должен реализовывать интерфейс и проверять что реализует
ВС
Но этого ведь не хватит
RL
Так в принципе врядли такой механизм есть.
Если даже какая-то библиотека сломается, то заметим мы только тогда, когда в сервисе обновим зависимость от данной библиотеки
Если даже какая-то библиотека сломается, то заметим мы только тогда, когда в сервисе обновим зависимость от данной библиотеки
RS
теоретически это было бы возможно
1. если экспортированные переменные/константы/функции/типы изменились - мы поломали обратную совместимость и это major increment
2. если что-то добавилось, то это feature increment
3. всё остальное это minor increment
1. если экспортированные переменные/константы/функции/типы изменились - мы поломали обратную совместимость и это major increment
2. если что-то добавилось, то это feature increment
3. всё остальное это minor increment
ВС
В эту логику не укладываются возвращаемые ошибки
RS
да, нюансы есть
RS
я про то что статический анализ кода мог бы, теоретически, определить, поломалась ли обратная совместимость, или нет
RS
в случае динамики конечно есть ограничения