что

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

тип "я пробывал в гостях у друга до 6 вечера"? )

напробывались у друга :)

что

Пробывал (был)

серьёзно? а как так... citation needed

а ещё сейчас за англ пояснят

Пробывал (был)

лулка (лул) затралил (трал) пирдак (пир)

давайте определимся. есть такое слово пробывал (был), которое не имеет отношения к пробовал (проба)

давайте определимся. есть такое слово пробывал (был), которое не имеет отношения к пробовал (проба)

не уверен, что есть слово "пробывал", по крайней мере не могу его найти в словаре, есть слово "пребывал" (был где-то)

ну бывал то точно есть

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

пробыл вместо пробывал

пробыл вместо пробывал

+

не уверен, что есть слово "пробывал", по крайней мере не могу его найти в словаре, есть слово "пребывал" (был где-то)

на вики словаре есть. пишут устаревшее

tkbo

чет не понимаю к чему эта ебля с open final обязательном указании override

чет не понимаю к чему эта ебля с open final обязательном указании override

effective java

там обоснование почему это удобно?)

da

ок спс)

чет не врубаюсь в сиалед классы. похоже на энамы и единственный кейс где применяется в доках - when-is . зачем они вообще?

У enum'a не может быть разных наборов полей

тоже не знаю пчастых кейсов для силед классов)

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

чет не врубаюсь в сиалед классы. похоже на энамы и единственный кейс где применяется в доках - when-is . зачем они вообще?

Можешь почитать про кейс-классы в Scala, они тоже самое или про union-типы. Вот на википедии чуток описано про обо https://en.wikipedia.org/wiki/Tagged_union

спасибо

Последнее время только на них и инвариантные модели в биз. домене, но я правда без OOP вообще пишу.

если писать в ооп они могут вообще никогда не пригодится?

В джаве же без них живут)

ну там мног обез чего живут)

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

ну например ты можешь сделать двух разных наследников у класса и по разному определить у них реализацию метода либо можешь сделать енум с полями и глобальную функцию, которая через when обходит. и то и другое вроде одинаково легко тестируется и в целом взаимозаменяется. ну плюсы/минусы вроде можно повыдумывать

попробуй сделать парсер в ast. вроде ощущается в таком случае профит

если писать в ооп они могут вообще никогда не пригодится?

Вон @HeapyHop говорил что сделал из него такое (воспроизвел по памяти) sealed class Result<out T> class Success<T>(val value:T): Result<T>() class Failed(e: Exception): Result<Nothing>() Это типа как Option в java, чуток функциональщины в ООП языке. Для чего-то большего наверное не пригодится. А вот Бреслав объясняет, как sealed class в противовес ООП решает expression-problem https://youtu.be/9x6utkLDBs8?t=14m7s

спасибо)

Вон @HeapyHop говорил что сделал из него такое (воспроизвел по памяти) sealed class Result<out T> class Success<T>(val value:T): Result<T>() class Failed(e: Exception): Result<Nothing>() Это типа как Option в java, чуток функциональщины в ООП языке. Для чего-то большего наверное не пригодится. А вот Бреслав объясняет, как sealed class в противовес ООП решает expression-problem https://youtu.be/9x6utkLDBs8?t=14m7s

хз зачем там <Nothing>

Поправил код (писал без IDEA)

не говорю что его там обязательно нет. просто не знаю зачем он там

Нужно тип проставить, я же наследуюсь от дженерик типа

ну да

https://github.com/FineCinnamon/Katz/blob/master/katz/src/main/kotlin/katz/data/Option.kt#L118

тут ещё забавней

Когда у кейса нет аргументов в конструкторе (у Failed есть) я тоже обычно object использую.

Мне еще кажется что when (x) { is A -> {…}; is B -> {…}, …} уже никогда не оптимизируют (Бреслав вон еще в 2013 обещал) - тк sealed класс это редкий кейс, а Hotspot все сам оптимизируют. Страдают только полтора андроид разработчка, которые пытаются “паттернматчить” на далвике.

Ребят, как такую ситуацию в котлине реализовать?

(имеются в виду дженерики)

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

читал

там все печально

в данном у вас случае in AbstractPresenter

в данном у вас случае in AbstractPresenter

неа, там инвариантность

есть дженерик является типом поля, то он находится в инвариантной позиции

T:AbstractPresenter?

неа, там инвариантность

Наверное имели ввиду ко или контр вариативность

Ctrl+Alt+Shift+K

Наверное имели ввиду ко или контр вариативность

вот там как раз таки не "ко" и не "контра"

Ctrl+Alt+Shift+K

это не поможет, тут все сложно для котлин-плагина )

ERROR: S client not available

abstract class AbstractView<T : AbstractPresenter> { lateinit var presenter: T }

abstract class AbstractView<T : AbstractPresenter> { lateinit var presenter: T }

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

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

не пойму что вы хотите. вот: open class AbstractPresenter class SimplePresenter : AbstractPresenter() abstract class AbstractView<T : AbstractPresenter> { lateinit var presenter: T } class SimpleView : AbstractView<SimplePresenter?) что не так? как вам нужно?

http://jetbrains.github.io/kotlin-spec/#_finite_bound_restriction

тогда такой вопрос: что мне указывать в дженериках в этих двух местах?

оценку такого кода на котлине я дать не могу, но вы подумайте над архитектуруй. Вы что-то не то совсем творите.

оценку такого кода на котлине я дать не могу, но вы подумайте над архитектуруй. Вы что-то не то совсем творите.

Краткое описание этого кода: Даны абстрактные классы для MVP. В дженерике AbstractView декларируется презентер, который будет полем для данной вью и будет делать takeView и dropView в необходимых местах. В дженерике AbstractPresenter декларируется вью, которая будет приниматься этим презентером в методах takeView и dropView. Model можно опустить, она тут роли не играет

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

Покажи код на джаве этот

А ну вы просто затираете дженерик

Тогда котлин все правильно делает :)

вот там как раз таки не "ко" и не "контра"

Лол. Ок

Лол. Ок

что не так?

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

Бомбануло же как у меня mPresenter

Убивал бы

Интересно, а есть выражение generic-hell (по типу callback-hell)? Когда вижу такое в чатах про андроид-архитектуру, это всегда приходит на ум.

Интересно, а есть выражение generic-hell (по типу callback-hell)? Когда вижу такое в чатах про андроид-архитектуру, это всегда приходит на ум.

фух. 3 раза начинал писать - одни маты выходили:)

Интересно, а есть выражение generic-hell (по типу callback-hell)? Когда вижу такое в чатах про андроид-архитектуру, это всегда приходит на ум.

есть)

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

ну ладно я тут проиграл. недостаточно проснулся чтобы гуглить но лол могу написать

Кстати в Kotlin есть магическая аннотация @UnsafeVariance, для блокировки таких ошибок.

попробуй так: open class AbstractView<P : ViewPresenter<in View>>(context: Context, attrs: AttributeSet) : FrameLayout(context, attrs)abstract class AbstractPresenter<V> : ViewPresenter<V>() where V : View, V : IView

попробуй так: open class AbstractView<P : ViewPresenter<in View>>(context: Context, attrs: AttributeSet) : FrameLayout(context, attrs)abstract class AbstractPresenter<V> : ViewPresenter<V>() where V : View, V : IView

у меня не флоу, а кондуктор, там все немного сложнее )