супер!!

Дружит. Но классы нужно делать open, так как realm не дружит с final классами

правда датаклассы не получится юзать с ним

бля

я как раз про дата подумла

хотя может щас можно. я еще на 1.0 котлина пробовал

когда нельзя была наследовать датаклассы

Нет, сейчас тоже нельзя.

А кто скажет в чем прикол sealed классов?

А кто скажет в чем прикол sealed классов?

В том, что компилятор может гарантировать, что все наследники заранее известны.

На этом приколы заканчиваются

И что это даёт?

И что это даёт?

when, гарантирующий, что все варианты будут перебраны, например (exhaistive when)

прикол

дефолт кейс не нужно указывать это серьезно весь прикол?

дефолт кейс не нужно указывать это серьезно весь прикол?

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

ну да

я имел в виду этот прикол

Это недостаточно круто?)

дефолт кейс не нужно указывать это серьезно весь прикол?

Тебе мало этого? Это решает expression problem и можно добавлять операции, не изменяя классы.

достаточно прикольно!

Тебе мало этого? Это решает expression problem и можно добавлять операции, не изменяя классы.

Есть пример?

Есть пример?

маркер-интерфейс Type из java.lang.reflect ?

Есть пример?

У Бреслава есть пример на youtube с Expr Num Var (взятый конечно из scala)

Есть пример?

Классика: sealed class Option<out T : Any> class Some<T : Any>(val value: T) : Option<T>() object None : Option<Nothing>()

У Бреслава есть пример на youtube с Expr Num Var (взятый конечно из scala)

Этот же пример в официальной доке Kotlin)

У Бреслава есть пример на youtube с Expr Num Var (взятый конечно из scala)

Я этот пример что раз видел но арименения не нашел. Мб мозг не в том направлении рвботает

Ему вообще хрен знает сколько лет. Одерски его скорее всего тоже откуда то взял.

Я этот пример что раз видел но арименения не нашел. Мб мозг не в том направлении рвботает

Если у тебя ООП (г̶о̶л̶о̶в̶н̶о̶г̶о̶ ̶м̶о̶з̶г̶а̶ ?), то тебе и не нужно. В ООП свои механизмы.

Если у тебя ООП (г̶о̶л̶о̶в̶н̶о̶г̶о̶ ̶м̶о̶з̶г̶а̶ ?), то тебе и не нужно. В ООП свои механизмы.

Как в истинном ООП это сделать?

Как в истинном ООП это сделать?

Визитор, это же Бреслав и говорил в том видосике "Андрей Бреслав. Функции и данные в Kotlin"

Как в истинном ООП это сделать?

Силед классы?

Визитор, это же Бреслав и говорил в том видосике "Андрей Бреслав. Функции и данные в Kotlin"

Как передавать данные полиморфного формата.

Что-то сложный вопрос “данные по л(м?) иморфного формата” ? - что это такое?

ну тема в том что каждый случай передачи данных – случай их дальнешей обработки. поэтому вместо того чтобы на месте захватывать скоп и обрабатывать в when добавляешь метод в интерфейс, в который передаёшь нужный на текущий момент скоп. реализуешь обработку этих полиморфмных данных в классах.

гибкость when в том что это можно сделать лаконичней

ну и более явно когда читаешь код

Что-то сложный вопрос “данные по л(м?) иморфного формата” ? - что это такое?

Допустим, за привлечение проекта вознаградить можно процентом от продажи либо фиксированной суммой. sealed class Earning { class Percent(val value: Double) : Earning() class Fixed(val value: Double) : Earning() } Как это правильно делается в ООП? Если маркер-интерфейсом (java.lang.reflect.Type ?), то нет никакой гарантии, что не появится новый вариант и свитчи не поломаются.

вообще не понимаю про маркер интерфейсы. ну само выражение примерно понимаю, но как они заменяют свитчи - хз

на самом деле немного плохо для примера, что у них одинаковое содержимое. а ещё я вспомнил тут был огромный разговор про ооп ровно о том же самом

вообще не понимаю про маркер интерфейсы. ну само выражение примерно понимаю, но как они заменяют свитчи - хз

Ну, тот пример, который я два раза пытаюсь привести: интерфейс Type не несёт никакого контракта и нет явного способа гарантировать проверку всех возможных его реализаций — Class, ParameterizedType, ArrayType и т. д..

на самом деле немного плохо для примера, что у них одинаковое содержимое. а ещё я вспомнил тут был огромный разговор про ооп ровно о том же самом

Да, поэтому добавим-ка туда вознаграждение печеньками.

Допустим, за привлечение проекта вознаградить можно процентом от продажи либо фиксированной суммой. sealed class Earning { class Percent(val value: Double) : Earning() class Fixed(val value: Double) : Earning() } Как это правильно делается в ООП? Если маркер-интерфейсом (java.lang.reflect.Type ?), то нет никакой гарантии, что не появится новый вариант и свитчи не поломаются.

Ну так и нужно поступать в ООП стиле (по заветам Егора) https://i.gyazo.com/7b9c043248bdcc54bd5d64d91df1aa03.png

Ну так и нужно поступать в ООП стиле (по заветам Егора) https://i.gyazo.com/7b9c043248bdcc54bd5d64d91df1aa03.png

User может находиться в таком слое, что Reward не будет ничего о нём знать.

Я всё же считаю, что пассивные объекты тоже имеют право на жизнь.

Ну это уже ваши частные проблемы архитектуры. Можно в @Android_Architecture что они там думают. (Я вообще за ФП в Kotlin)

Допустим, за привлечение проекта вознаградить можно процентом от продажи либо фиксированной суммой. sealed class Earning { class Percent(val value: Double) : Earning() class Fixed(val value: Double) : Earning() } Как это правильно делается в ООП? Если маркер-интерфейсом (java.lang.reflect.Type ?), то нет никакой гарантии, что не появится новый вариант и свитчи не поломаются.

enum)

User может находиться в таком слое, что Reward не будет ничего о нём знать.

так всё равно ты как-нибудь дойдёшь до такого скопа что user и earning встретятся и на месте обработаешь данные для двух случаев earning

enum)

У enum данные не полиморфные. Получается, что за каждым элементом enum нужно закреплять класс, и, о ужас, кастить данные в него.

так всё равно ты как-нибудь дойдёшь до такого скопа что user и earning встретятся и на месте обработаешь данные для двух случаев earning

Ну вот. Они друг о друге не знают, а обработать их надо. В этом и вопрос.

btw, вчера на митапе в Питере ruX показывал отличные примеры с sealed классами.

Я выше уже упоминал про паттерн (костыль) - Visitor, вроде подходит. Там можно вообще какие угодно операции намутить в будущем (супер расширяемость и гибкость). Плюс он быстрее ”when” из-за прямого диспатчинга.

* What went wrong: Execution failed for task ':app:transformClassesWithJarMergingFor<FlavorName>Debug'. > com.android.build.api.transform.TransformException: java.util.zip.ZipException: duplicate entry: org/xmlpull/v1/XmlPullParser.class HELP

XmlPullParser через либу подключен?

нет https://gist.github.com/jordan1997/b6c7bedbb39eeecce51e1515db492bdbє но http://prntscr.com/fkj8x9

:app:dependencies не помогло?

нет https://gist.github.com/jordan1997/b6c7bedbb39eeecce51e1515db492bdbє но http://prntscr.com/fkj8x9

feelgood.jpeg (обмазался так обмазался)

нет https://gist.github.com/jordan1997/b6c7bedbb39eeecce51e1515db492bdbє но http://prntscr.com/fkj8x9

Не открывается.

https://gist.githubusercontent.com/jordan1997/b6c7bedbb39eeecce51e1515db492bdb/raw/a3dc6ee0086f4285602060bcc7e3c1acc1771e96/gistfile1.txt

а так?

Не открывается.

https://gist.github.com/jordan1997/b6c7bedbb39eeecce51e1515db492bdb

Да тут и так все ясно. Идет конфликт с Андройдовским XmlPullParser.

как фіксить?

А оказаться ни как?

ERROR: S client not available

Да тут и так все ясно. Идет конфликт с Андройдовским XmlPullParser.

Это ясно и без build.gradle. А вот какие библиотеки его втащили?

ситуация такая что тесты на ява а код на Котлин ошибку на следующую команду /gradlew —no-daemon ":app:assemble<FlavorNaem>DebugAndroidTest" ":app:assemble<FlavorName>Debug"

:app:assemble<FlavorNaem>DebugAndroidTest"

FlavorNaem

В libs есть что-нибудь?

Короче, нужно смотреть граф зависимостей и выяснять, кто притащил парсер.

В libs есть что-нибудь?

да http://prntscr.com/fkjdvl это мои

Нет ли в них этого парсера?

есть но к переводу проекта на Котлин все было ок

есть но к переводу проекта на Котлин все было ок

мб после перехода он полностью пересобрался и проблема всплыла.

это CI машина

ок как решить я не могу просто удалить xmlParse из библиотек?

Давайте глянем внимательней на список зависимостей Запустите градловую таску dependencies найти ее можно вот тут https://snag.gy/iz0Ace.jpg

Как выполнится, скидывайте логи. Посмотрим какая из либ шалит

http://prntscr.com/fkjjjv

а так если от app

парсер есть в powermock и в какой-то из подключённых библиотек. Нужно убрать его откуда-то.

Вот тут +--- org.powermock:powermock-classloading-xstream:1.6.4 | +--- org.powermock:powermock-classloading-base:1.6.4 (*) | \--- com.thoughtworks.xstream:xstream:1.4.2 | +--- xmlpull:xmlpull:1.1.3.1 | \--- xpp3:xpp3_min:1.1.4c

Что забавно, его нет в списке зависимостей, что вы скидывали ранее. Я так понимаю, вы почистили его от тестовых зависимостей?

да

Тест https://gist.github.com/3e17312da1651decd46b529c982dacc9.git

как убрать из powerMock ?

@sdi_linch можете подсказать?

Можно попробовать исключить xmlpull из зависимостей. Но в данном случае я не ручаюсь за работоспособность тестов

Дело в том, что тут идет конфликт имен а не простой конфликт версий. Скорее всего xstream использует методы и классы отсутствующие в Android

Советю присмотреться к другим решениям

а вот такой вопрос, кто ретрофитом пользуется, все модельки nullable типизируете?

нет. зачем

а вот такой вопрос, кто ретрофитом пользуется, все модельки nullable типизируете?

нет конечно

а как? надеятся на бек?

и падать по любому чиху

как вариант свои мапервы для каждой модели писать