Size: a a a

Kotlin Community

2020 April 08

AN

Alexander Nozik in Kotlin Community
Andrew Mikhaylov
А контракт на некий приаттаченый, возможно снаружи, к классу объект -- совсем сказка, тогда можно не ограничиваться компаньонами и перестать таскать кастомные сериализаторы в подавляющем большинстве случаев, к примеру :) И не вешать на один компаньон несколько ответственностей, если он уже есть и не фабрика при этом.
Там проблема имплиситов начинается. Компаньоны хороши тем, что они известны всегда
источник

AN

Alexander Nozik in Kotlin Community
(
Знаете, кто так умеет? Тайпклассы
Нэ. Тайп-классы вот как раз внешние там всякие орфаны-имплиситы.
источник

BP

Bogdan Panchenko in Kotlin Community
(
Знаете, кто так умеет? Тайпклассы
Наша песня хороша, начинай сначала
источник

(

( in Kotlin Community
Alexander Nozik
Нэ. Тайп-классы вот как раз внешние там всякие орфаны-имплиситы.
Так могут быть и не орфаны
источник

AN

Alexander Nozik in Kotlin Community
(
Так могут быть и не орфаны
Если оторвать орфанов, то тайп-классы теряют смысл в языке с нормальными интерфейсами. Тебе все равно надо объявлять поведения там же, где и сам класс.
источник

BV

Boris Vanin in Kotlin Community
Alexandr Emelyanov
на java работает отлично
Работает отлично, да, но смысла в нем особого нет, не зависимо от языка
источник

(

( in Kotlin Community
Alexander Nozik
Если оторвать орфанов, то тайп-классы теряют смысл в языке с нормальными интерфейсами. Тебе все равно надо объявлять поведения там же, где и сам класс.
но тайпклассы могут объявлять конструкторы
источник

AE

Alexandr Emelyanov in Kotlin Community
Boris Vanin
Работает отлично, да, но смысла в нем особого нет, не зависимо от языка
как сказать. вполне себе kpi тестирования
источник

AN

Alexander Nozik in Kotlin Community
(
но тайпклассы могут объявлять конструкторы
Верно, только это уже не тайп-классы.
источник

(

( in Kotlin Community
Alexander Nozik
Верно, только это уже не тайп-классы.
с чего бы?
источник

AN

Alexander Nozik in Kotlin Community
Alexandr Emelyanov
как сказать. вполне себе kpi тестирования
А зачем?
источник

BV

Boris Vanin in Kotlin Community
Alexandr Emelyanov
как сказать. вполне себе kpi тестирования
Kpi, да, который показывает примерно ничего. Люди зная, что оно будет проверяться, делают тесты так, чтобы это число было больше, вместо нормальных тестов
источник

AN

Alexander Nozik in Kotlin Community
(
с чего бы?
С того что тайп-классы это замена интерфейсов. Контракт на конструкторы или компаньоны - это маленький побочный продукт. Если этим ограничиться - лично меня все устраивает.
источник

AE

Alexandr Emelyanov in Kotlin Community
Alexander Nozik
А зачем?
как минимум позволяет оценить количество протестированного кода.
вообще по нему удобно анализировать места, которые еще не покрыты тестами и которые стоит покрыть. особенно это хорошо когда большая система начинает покрываться тестами, но это немного другая проблема, да
источник

(

( in Kotlin Community
Alexander Nozik
С того что тайп-классы это замена интерфейсов. Контракт на конструкторы или компаньоны - это маленький побочный продукт. Если этим ограничиться - лично меня все устраивает.
а в каком месте тайпклассы не тайпклассы, если умеют объявлять конструкторы?
источник

AE

Alexandr Emelyanov in Kotlin Community
Boris Vanin
Kpi, да, который показывает примерно ничего. Люди зная, что оно будет проверяться, делают тесты так, чтобы это число было больше, вместо нормальных тестов
ну это культура написания тестов и всего
источник

BV

Boris Vanin in Kotlin Community
Например, можно существенно увеличить покрытие просто подняв спринг приложение. И это ничего не говорит о его протестированности
источник

AN

Alexander Nozik in Kotlin Community
(
а в каком месте тайпклассы не тайпклассы, если умеют объявлять конструкторы?
В том, где тайп-классы байндятся к типу по месту и объявляются отдельно от самого типа
источник

BV

Boris Vanin in Kotlin Community
То, что код был выполнен не говорит о его протестированности примерно ничего 🤷‍♂
источник

AN

Alexander Nozik in Kotlin Community
Alexandr Emelyanov
как минимум позволяет оценить количество протестированного кода.
вообще по нему удобно анализировать места, которые еще не покрыты тестами и которые стоит покрыть. особенно это хорошо когда большая система начинает покрываться тестами, но это немного другая проблема, да
Я не уверен, что полное покрытие тестами - это маст хэв. В питоне - да
источник