Вот радует, что над языком плотно работают

Какую статью по "функциональному Котлину" стоит сделать для (инвайта) хабра? Как варианты: - Обзор библиотеки funKTionale - "Реализации Монад и функторов в Android с помощью Kotlin и без практического применения ?"

лучше с применением

обзор мне кажется не потянет на инвайт (хотя кто знает) а про монады норм (только зачем андроид?)

» "Реализации Монад и функторов в Android с помощью Kotlin и без практического применения https://github.com/h0tk3y/kotlin-monads (не андроид правда, да)

обзор мне кажется не потянет на инвайт (хотя кто знает) а про монады норм (только зачем андроид?)

Чтобы скалисты не заклевали (да я и Android разработчик)

лучше с применением

А если так Практическое применение ФП (без RX) при разработки мобильных приложений на Kotlin?

Я тут недавно на прикольный перевод наткнулся про функторы и монады https://habrahabr.ru/post/183150/

А если так Практическое применение ФП (без RX) при разработки мобильных приложений на Kotlin?

и будет ещё одна капитанская статья про map, filter, optional?

или как карировать-перекарировать андроид (без Rx)?

А если так Практическое применение ФП (без RX) при разработки мобильных приложений на Kotlin?

это сильно лучше звучит

или как карировать-перекарировать андроид (без Rx)?

вот это было бы интересно. но, кажется, краткий ответ "никак"

(без Rx) конечно никак

вот это было бы интересно. но, кажется, краткий ответ "никак"

Для этого есть funKTionale и там нет ничего особо интерсного

как это никак, funKtionale же поможет

Хорошая либа

(без Rx) конечно никак

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

да я шучу ж, сорян

Для этого есть funKTionale и там нет ничего особо интерсного

я хотел бы каррировать создания view или даже сервисов. О_о но архитектура андроида не позволит без особых извратов так делать

да я шучу ж, сорян

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

/stat@combot

combot.org/chat/-1001032833563

Вообще не люблю RX тк это ну просто мейнтримный-мейнстрим. На каждой Android конфе обязательно есть о нем доклады - кто хотел уже все выучил.

я хотел бы каррировать создания view или даже сервисов. О_о но архитектура андроида не позволит без особых извратов так делать

да, у андроида есть большая проблема с тем, что он всегда сам всё инстранцирует — с этим тяжело жить

Хочется поговорить о реальном ФП с чистыми функциями и алг. типами, а не OOП + Стримы (или Рективные-Стримы)

Вообще не люблю RX тк это ну просто мейнтримный-мейнстрим. На каждой Android конфе обязательно есть о нем доклады - кто хотел уже все выучил.

И обычно он используется чтобы победить плохой бэк или банальный ЖЦ :)

ребят, может кто подскажет почему он недоумевает?

все работает, просто не пойму почему студия варнинг вешает

потому что он не знает this типа V или нет

так а почему он этого не знает, this же реализует интерфейс, из иерархии для V

нет, он реализует IBaseMvpView, а реализует ли он V компилятор не знает

а, там in

тогда нужно подумать

просто интересно, пытаюсь это понять

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

просто интересно, пытаюсь это понять

какая сигнатура AttachView?

[оффтоп] для вставки кода надо 3 единых кавычки поставить?

[оффтоп] для вставки кода надо 3 единых кавычки поставить?

аха

interface IBaseMvpPresenter<in V : IBaseMvpView> { fun attachView(view: V) fun detachView() }

[оффтоп] какой-то generic-hell :D

ну да, всё вроде верно, this к V преобразовать нельзя

interface IBaseMvpPresenter<in V : IBaseMvpView> { fun attachView(view: V) fun detachView() }

Я бы написал out V, потому что V extends IBaseMvpView...

или ты за другое место

ну да, они специально называются in и out чтобы понимать, что если in значит ты его передаешь в качестве параметра, а если out то возвращаешь

т.е. нельзя объявить тип как in и возвращать его или out и передавать его в параметр

туплю, мне кажется, там не должно быть variance

туплю, мне кажется, там не должно быть variance

возможно, да, но это тонкий вопрос — зависит от того какой смысл у дженерика

я потом от этого класса наследуюсь и наследую интерфейсы View и Presenter , передаю этих наследников в него

если вам будет интересно и будет время, то могу отрисовать uml

а то так мы на кофейной гуще гадаем

я мало инфы, наверно, даю

да не, я тут поковырял, без тайпкаста вроде сделать не выйдет

как вообще ты сам можешь быть уверен, что this это V?

this реализует интерфейс из иерархии V

как вообще ты сам можешь быть уверен, что this это V?

Как вы обходитиесь с тем что CompletableFuture.thenAccept() возвращает CF<Void>, а не CF<Unit>? (странно что в Kotlin для Java8 нет готового экстеншен-метода)

this реализует интерфейс из иерархии V

Но он не является V, он является какой-то реализацией того же интерфейса, что и реализует V.

this реализует интерфейс из иерархии V

значит ли это, что он имеет тип V к которому ты его кастишь?

тип он имеет однозначно другой

дженерик заточен исключительно на интерфейсы

тип он имеет однозначно другой

тогда вероятно компилятор поступает мудро, что не дает скастить this к V?

может быть

в рантайме все работает норм

холиварный вопрос, но все же. есть ли в котлине то, что нельзя написать в джаве?

кроме вещей связанных с inline

в рантайме все работает норм

думаю, потому что этого каста в рантайме нету

если и есть, то оно вам никогда не пригодится. На выходе байт код jvm, какая разница на чем оно написано?

холиварный вопрос, но все же. есть ли в котлине то, что нельзя написать в джаве?

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

холиварный вопрос, но все же. есть ли в котлине то, что нельзя написать в джаве?

смотря что считать "нельзя"

вот, в джаве нету корутин, например

холиварный вопрос, но все же. есть ли в котлине то, что нельзя написать в джаве?

@JvmSynthetic, unchecked checked exceptions

их так вот просто взять и "написать" нельзя, хотя это не мешает делать их библиотекам

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

а такие есть?

ну допустим refeid дженерики

хотя если руками инлайнить методы...

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

на уровне байт-кода можно повторить что угодно что делает котлин, потому что он байткод и делает

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

reified дженерики не на уровне байт-кода

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

это вот точно элементарно повторить

это же просто синглтон

на уровне байт-кода можно повторить что угодно что делает котлин, потому что он байткод и делает

Нет, байт-код позволяет очень много того, что не позволят ни Java, ни Kotlin

там на уровне байткода идет инициализация final переменной в нестатическом блоке

как такое в джаве написать?

холиварный вопрос, но все же. есть ли в котлине то, что нельзя написать в джаве?

Что вы тут развели. Вот https://kotlinlang.org/docs/reference/comparison-to-java.html и можно закрывать вопрос.

Нет, байт-код позволяет очень много того, что не позволят ни Java, ни Kotlin

но моё высказывание этому не противоречит

но моё высказывание этому не противоречит

Вероятно, я неверно понял высказывание.

там на уровне байткода идет инициализация final переменной в нестатическом блоке

че то я не то сморозил

ща

почти то сказал

там в нестатическом блоке инициализируется final static

там в нестатическом блоке инициализируется final static

Да, забавно.