ТК его идеи очень радикальны в плане ооп

А в том что люди даже "стандартное" ооп осилить не могут

Бреслав сказал что все эти ваши "фп, ооп, what ever p" фигня

Когда рассказывал про Котлин на jpoint

https://youtu.be/rYRnvMq41uw?t=12m24s

А в том что люди даже "стандартное" ооп осилить не могут

Зачем возводить ООП в абсолют?

Зачем возводить ООП в абсолют?

Зачем возводить <name> в абсолют?

Зачем возводить <name> в абсолют?

И? Вопрос справедлив в отношении любого акронима, прозвучавшего в этом чате. В чём противоречие?

И? Вопрос справедлив в отношении любого акронима, прозвучавшего в этом чате. В чём противоречие?

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

Спорить не буду - всё так.

Неужели никто не слышал про такую штуку как clean architecture,про то,что на data layer'e и domain'e у тебя разные сущности и на уровне того куда ты сторишь и как тебе это с сети приходит там может быть хоть морзянкой тип описан,а вот на уровне домейна эта должна быть правильно представленная моделька

Речь не об архитектуре: этот "свич по типам" неизбежен. В маппере ли, в (де)сериализаторе ли - не важно, но он будет. Независимо от того, сколько слоёв абстракции накрутить, во сколько декораторов завернуть.

Так, я так понял там выше спорили как нужно делать: GithubLink(val url: String): Link или Link(val type: LinkType, val url: String)

я правильно понял?

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

Как по мне, так первый вариант не согласуется с утверждением "Предпочитайте компизицию наследованию"

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

Если Link sealed класс, то вроде и для ФП хорошо подходит

Если Link sealed класс, то вроде и для ФП хорошо подходит

В кейсе, с которого всё началось, sealed-класс предпочительнее, да. Но радикально настроенный Иван утверждал о вещах, которые шире конкретного примера (читать в районе утверждений про говнокод). Я попытался донести мысль, что за пределами его кода (JSON, БД, ...) потребуется знание о "типе" объекта в его сериализованном виде.

Последнее означает ровно то, что там появится что-то такое "type: SomethingType".

можно/нельзя - не слишком ли возводят в абсолют некоторые вещи?

Контекст - можно или нельзя согласно создателю Clean

И че получили с бекенда с тем и работаем

Я лично для каждого слоя свою делаю, имхо, студия с автокомплитом делает это быстрым действием

В кейсе, с которого всё началось, sealed-класс предпочительнее, да. Но радикально настроенный Иван утверждал о вещах, которые шире конкретного примера (читать в районе утверждений про говнокод). Я попытался донести мысль, что за пределами его кода (JSON, БД, ...) потребуется знание о "типе" объекта в его сериализованном виде.

Разделяй домейн слой и дата

Контекст - можно или нельзя согласно создателю Clean

не знаю, из всех правил есть исключения. Порой нет времени городить кучу классов для соблюдения какого либо правила. Я не спорю и верю что теория "разбитых окон" работает и в разработки, но бизнес и пользователи не должны страдать от твоих убеждений и чистоты твоей архитектуры

не знаю, из всех правил есть исключения. Порой нет времени городить кучу классов для соблюдения какого либо правила. Я не спорю и верю что теория "разбитых окон" работает и в разработки, но бизнес и пользователи не должны страдать от твоих убеждений и чистоты твоей архитектуры

Так никто и не говорит, что жизненно необходимо следовать ей

Согласно clean, появляются правила. И уже ваш выбор, следовать ли им, и каким, или нет

Контекст - можно или нельзя согласно создателю Clean

Это вопрос? Не думаю что uncle bob в курсе по android контекст. Да и Shu-Ha-Ri конечно никто не отменял, но админы из того чата мягко говоря зациклились на своей “архитектуре”.

Это вопрос? Не думаю что uncle bob в курсе по android контекст. Да и Shu-Ha-Ri конечно никто не отменял, но админы из того чата мягко говоря зациклились на своей “архитектуре”.

не вопрос (контекст - смысловое окружение, не андроид-контекст)

Это вопрос? Не думаю что uncle bob в курсе по android контекст. Да и Shu-Ha-Ri конечно никто не отменял, но админы из того чата мягко говоря зациклились на своей “архитектуре”.

что такое Sha-Ha-Ri? гугл выдает какую ту дичь

что такое Sha-Ha-Ri? гугл выдает какую ту дичь

Облажался с первым словом ? (правильный вариант спокойно гуглится)

думаю про это речь https://martinfowler.com/bliki/ShuHaRi.html

точно, Сюхари же

Парни, ни у кого студия не тормозит когда печатаете на котлине?

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

хмм, я прям запарился уже

пару букв и завис на 300мс

ну кстати щас сижу на eap

swift заорал в сторонке

ну кстати щас сижу на eap

щас все ок. видно что над скоростью поработали

Подскажите, а в котлине можно сделать трейты, как в скале?

Подскажите, а в котлине можно сделать трейты, как в скале?

Нет. Есть же объектная композиция.

@Harmonizr где можно почитать?

Нашёл лишь объектную ДЕкомпозицию)

https://en.wikipedia.org/wiki/Object_composition

Лооол, та же статья есть на украинском. На русском нет.

https://en.wikipedia.org/wiki/Composition_over_inheritance

@Harmonizr понял, о чём ты говоришь. Разве нельзя считать использование трейтов композицией?

Парни, ни у кого студия не тормозит когда печатаете на котлине?

был такой баг, перезагрузил студию ;D

m.accuweather.com/en/privacy#adChoices http://m.accuweather.com/en/privacy#adChoices?partner=asustek

был такой баг, перезагрузил студию ;D

Сейчас попробую)

У тебя эмулятор запущен?

@Harmonizr понял, о чём ты говоришь. Разве нельзя считать использование трейтов композицией?

http://www.yegor256.com/2017/03/07/traits-and-mixins.html

Нет

мне казалось просто пк не справляется уже студия + эмулятор + хром + пару софтин = 10 гб памяти было забито

и вот такая же фигня была

как у тебя

Подскажите, а в котлине можно сделать трейты, как в скале?

А что ты под этим подразумеваешь? Что ты конкретно хочешь сделать? Просто вспомнил, что задолго до релиза, интерфейсы в Kotlin тоже назывались трейтами.

Угу, просто java норм вертится, а Котлин заикается)

трейты это которые подмешивают некое поведение в класс?

Да, они самые.

экстеншионы этого не могут заменить?

по мне такие схожие задачи решают, только экстеншионы лучше из-за того что тебе их явно внедрять не надо

Нет. Ну, грубо говоря, я хочу такую штуку запилить. Сделать трейты вида ProgressBar / Toaster и тому подобное. У них реализовать методы соответствующие (showProgress, hideProgress, toast), и иметь возможность примешивать к вьюхам сразу реализацию. Собирать вьюху из готовых заранее кусков.

Нет. Ну, грубо говоря, я хочу такую штуку запилить. Сделать трейты вида ProgressBar / Toaster и тому подобное. У них реализовать методы соответствующие (showProgress, hideProgress, toast), и иметь возможность примешивать к вьюхам сразу реализацию. Собирать вьюху из готовых заранее кусков.

Электроны для интерфейса я бы сделал

Экстеншены

Нет. Ну, грубо говоря, я хочу такую штуку запилить. Сделать трейты вида ProgressBar / Toaster и тому подобное. У них реализовать методы соответствующие (showProgress, hideProgress, toast), и иметь возможность примешивать к вьюхам сразу реализацию. Собирать вьюху из готовых заранее кусков.

Можно попробовать сделать интерфейсами с дефолтными методами, но там сильные ограничения есть

Нет. Ну, грубо говоря, я хочу такую штуку запилить. Сделать трейты вида ProgressBar / Toaster и тому подобное. У них реализовать методы соответствующие (showProgress, hideProgress, toast), и иметь возможность примешивать к вьюхам сразу реализацию. Собирать вьюху из готовых заранее кусков.

А можешь накидать пример кода на Scala? Я просто с трудом представляю как это сделать без имплиситов (в scala я не очень разбираюсь).

ERROR: S client not available

Нет. Ну, грубо говоря, я хочу такую штуку запилить. Сделать трейты вида ProgressBar / Toaster и тому подобное. У них реализовать методы соответствующие (showProgress, hideProgress, toast), и иметь возможность примешивать к вьюхам сразу реализацию. Собирать вьюху из готовых заранее кусков.

С трейтами ты можешь добавить это поведение только единожды. С композицией можно так: val loadProgress = ProgressView(loadProgressBar) val saveProgress = ProgressView(saveProgressBar)

Кроме того, в Котлине есть делегирование реализаций интерфейсов.

Вроде в котлине интерфейсы прокаченные

Можно тоже самое сделать

что в трейтах

@Harmonizr а вот тут я тебя начал понимать. Круто! Спасибо, попробую так.

Кроме того, в Котлине есть делегирование реализаций интерфейсов.

Это как?

Дефолтные методы?

Это как?

class DecoratedList : List by ArrayList() { override fun getSize(): Int = 100500 }

Это как?

https://kotlinlang.org/docs/reference/delegation.html

Спасибо!

class DecoratedList : List by ArrayList() { override fun getSize(): Int = 100500 }

Это спонтанный пример или в этом случае тоже есть какое-то преимущество над наследованием?

енумы это основной ботлнэк в андроиде. очень печальная история

Я надеюсь это троллинг

Это спонтанный пример или в этом случае тоже есть какое-то преимущество над наследованием?

Спонтанный пример. Преимущество — нет суперкласса. ?

Я надеюсь это троллинг

You should strictly avoid using enums on Android Где-то там было написано

ну то что это основной ботлнэк - это загнуто в кубе

Я надеюсь это троллинг

++

You should strictly avoid using enums on Android Где-то там было написано

их просто не РЕКОМЕНДУЮТ юзать

а не запрещают

Да блин, стоило тому адвокату снять видео, так сразу началось

Кто-нибудь рекомендует объединять несколько анонимных лисенеров в один класс? Memory footprint от анонимки должен быть аналогичен footprint'у от enum.

Есть такая рекомендация про энумы, что бы сэкономить пару классов, но в реальности влияние на размер приложения, количество методов и память мизерный и не заметный, микрооптимизация. Был небольшой холивар на эту тему даже, когда Кольт из Гугла стал эту рекомендацию форсить, а Вортон написал, что это херня, и был небольшой обмен мнениями в комментах

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

И снова, @IntDef порождают switch, когда у enum есть полиморфизм. Кто-нибудь избавлялся от полиморфизма в пользу switch в угоду производительности? Как вам результаты?

Это как всё должно быть плохо что бы несчастные пару enums в IntDef переводить

ну ладно ребят. я на самом деле просто иногда рофлю на тему этих енумов весь андроид строится на сраных интах и этих микрооптимизациях для кого то это часть культа как и нотация полей с буквы m

ну ладно ребят. я на самом деле просто иногда рофлю на тему этих енумов весь андроид строится на сраных интах и этих микрооптимизациях для кого то это часть культа как и нотация полей с буквы m

Нотация полей с m отвратительна.

Блин, на m у меня вообще триггер срабатывает

ее точно не надо использовать

конечно же во время депенденси инжекшонов и rxjava с сотнями лямбд на каждый чих это всё должно быть безразлично

ого

я думал меня с буквой m не поддержут