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

мне кажется все(ну по крайней мере большинство) из тех кто топит за ручную сборку и прочие kiss не заглядывали даже в gof

Насчёт gof - а вы читали критику паттернов проектирования? В курсе, что большую часть из них становится не нужной, если есть анонимные функции в языке, а остальные перекрываются таким формализмом общей алгебры, как монада? Вообще, мне периодически приходится не только писать код, но и рассказывать про программирование (занимаюсь репетиторством ради удовольствия). Вот заметил такую болезнь: паттерны головного мозга - когда школьник/студент легко понимает простые абстракции общей алгебры, но если перед началом занятий он уже пробовал паттерны, понятие монады может как-то осознать только когда скажешь ему, что это такой специальный билдер с хорошо определённым контрактом на операции.

В общем, прошить недостающую часть компилятора себе в голову - не лучшая идея, как по мне.

Ну это тоже самое что описать граф, а графы обычно описывают как две сущности: объект, и связь между объектами

описать граф можно кучей способов но главное, что по своей природе граф может иметь циклы когда мы заменяем объекты на id, всякие прокси и так далее - это просто такая попытка обмануть природу вещей, замаскировать циклы ООП трюками иногда это работает но иногда проще и удобнее хранить граф в его натуральной, естественной форме

описать граф можно кучей способов но главное, что по своей природе граф может иметь циклы когда мы заменяем объекты на id, всякие прокси и так далее - это просто такая попытка обмануть природу вещей, замаскировать циклы ООП трюками иногда это работает но иногда проще и удобнее хранить граф в его натуральной, естественной форме

А что такое натуральная и естественная форма хранения графа? Направленный граф, например, можно хранить в виде Map<Node, List<Node>>, где ключи - узлы, значения - список узлов, в которые можно пройти из узла. Это естественная форма?

А что такое натуральная и естественная форма хранения графа? Направленный граф, например, можно хранить в виде Map<Node, List<Node>>, где ключи - узлы, значения - список узлов, в которые можно пройти из узла. Это естественная форма?

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

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

приложение с динамической логикой, когда есть некоторый механизм в виде нормализованного ООП домена, инжектится все по интерфейсу и в местах где в зависимости от контекста (тип запроса, подтип отчета, которые строится по общему шаблону, в конце концов роль текущего пользователя) нужна кастомизация логики - инжектится прокси и по факту вызова в зависимости от контекста вызывается та реализация, которая сейчас нужна

это в какой-то степени стратегия получается

приложение с динамической логикой, когда есть некоторый механизм в виде нормализованного ООП домена, инжектится все по интерфейсу и в местах где в зависимости от контекста (тип запроса, подтип отчета, которые строится по общему шаблону, в конце концов роль текущего пользователя) нужна кастомизация логики - инжектится прокси и по факту вызова в зависимости от контекста вызывается та реализация, которая сейчас нужна

Передаёшь нужную стратегию лямбдой или несколькими, в зависимости от контекста.

Передаёшь нужную стратегию лямбдой или несколькими, в зависимости от контекста.

в document generation engine размером в 50+ классов в котором более 10+ подобных кастомизаций с 3-4 реализациями, которые еще могут комбинироваться?

ну можете дальше так жить :)

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

в document generation engine размером в 50+ классов в котором более 10+ подобных кастомизаций с 3-4 реализациями, которые еще могут комбинироваться?

Лямбды прекрасно комбинируются друг с другом. Большая часть ФП (комбинаторная логика, общая алгебра) про то, как всё со всем комбинировать, не получая при этом вложенных if/switch

Лямбды прекрасно комбинируются друг с другом. Большая часть ФП (комбинаторная логика, общая алгебра) про то, как всё со всем комбинировать, не получая при этом вложенных if/switch

я просто спорить не буду :) каждй все равно при своем мнении останется

приложение с динамической логикой, когда есть некоторый механизм в виде нормализованного ООП домена, инжектится все по интерфейсу и в местах где в зависимости от контекста (тип запроса, подтип отчета, которые строится по общему шаблону, в конце концов роль текущего пользователя) нужна кастомизация логики - инжектится прокси и по факту вызова в зависимости от контекста вызывается та реализация, которая сейчас нужна

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

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

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

я бы не давал таких поспешных заявлений

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

я просто спорить не буду :) каждй все равно при своем мнении останется

Да я и не призываю спорить. Я просто предлагаю вам посмотреть альтернативы, как ещё это решается без лишних проблем. Бандой четырёх проектирование не исчерпывается. Как по мне, так они продали под разнообразным соусом то, что называется лямбда абстракцией и частичным применением.

И вообще, они эти паттерны писали под C++, в котором, на тот момент, не было анонимных реализаций классов, лямбд и прочего. То есть, как раз и предлагали прошить в голову недостающую часть языка/компилятора в виде паттернов.

Тот же DI в функциональных языках с богатой системой типов (F#, Haskell) вполне может быть отдан на откуп компилятора, который, в зависимости от типа контекста подберёт нужную реализацию, статически свяжет её в выражении, где она используется, возможно ещё и заинлайнит для скорости.

И всё это с проверками типов и на этапе компиляции. В Kotlin так не всегда получится (система типов бедновата), но в большинстве случаев тоже реально.

А тут кто-то использовал Nginx-clojure на котлине, какие впечатления?

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

Я бы точно написал по другому, и все варианты отчётов с параметрами передавал явно в зависимости от ситуации. Ситуации явно заведомо известны. И тут удже компилятор будет моим другом. А вашим другом будет только внимательность. Нет кейс вообще не убедительный ¯\_(ツ)_/¯

И всё это с проверками типов и на этапе компиляции. В Kotlin так не всегда получится (система типов бедновата), но в большинстве случаев тоже реально.

Ну автоматом конечно не получится, имплиситов нет

Ну автоматом конечно не получится, имплиситов нет

Во первых есть в качестве Language Extension, во вторых, имплиситы для этого не нужны. Достаточно ad hoc полиморфизма.

Или вы про Kotlin?

Или вы про Kotlin?

Да про котлин

C хаскелем то всё понятно

Да про котлин

А я то, дурак, про Haskell подумал

Ребята, как лучше передать контекст в фрагмент который вызывается из dialogfragment?

Ребята, как лучше передать контекст в фрагмент который вызывается из dialogfragment?

https://t.me/android_ru

Я бы точно написал по другому, и все варианты отчётов с параметрами передавал явно в зависимости от ситуации. Ситуации явно заведомо известны. И тут удже компилятор будет моим другом. А вашим другом будет только внимательность. Нет кейс вообще не убедительный ¯\_(ツ)_/¯

ну ок, посмотрел бы я на расширяемость и гибкость кода и конфигурации)

ну ок, посмотрел бы я на расширяемость и гибкость кода и конфигурации)

Ну дак и зачем тогда писать на строготипизированном языке, пишите на динамике, ух там свобода действий

Ну дак и зачем тогда писать на строготипизированном языке, пишите на динамике, ух там свобода действий

это уже фанатизм, гибкость динамикой не определяется

с динамикой есть свобода отстрелить себе гениталии и не более

Ну построение отчёт - это по сути функция: (Data, Template) => Report А дальше - это уже pattern matching в чистом виде В котлине не хватает PartialFunction, которые можно комбинировать Так бы можно было описать каждый кейс отдельно и потом в одном месте сделать что то вроде val report: (Data, Template) -> Report = { reportA .orElse(reportB) .orElse(reportC) .andSoOn } Всё отлично расширяется и описывается нормально

Ну построение отчёт - это по сути функция: (Data, Template) => Report А дальше - это уже pattern matching в чистом виде В котлине не хватает PartialFunction, которые можно комбинировать Так бы можно было описать каждый кейс отдельно и потом в одном месте сделать что то вроде val report: (Data, Template) -> Report = { reportA .orElse(reportB) .orElse(reportC) .andSoOn } Всё отлично расширяется и описывается нормально

В котлине можно написать Option и PF к нему в 100 строк если по-минималке. Это не проблема же.

И паттерн-матчинг тоже, если видели наши с еще одним фанатично-фпшным товарищем посты, вполне себе реально сделать.

?? ??

В котлине можно написать Option и PF к нему в 100 строк если по-минималке. Это не проблема же.

Ну это то понятно)

Ну построение отчёт - это по сути функция: (Data, Template) => Report А дальше - это уже pattern matching в чистом виде В котлине не хватает PartialFunction, которые можно комбинировать Так бы можно было описать каждый кейс отдельно и потом в одном месте сделать что то вроде val report: (Data, Template) -> Report = { reportA .orElse(reportB) .orElse(reportC) .andSoOn } Всё отлично расширяется и описывается нормально

А кто вам мешает в Kotlin использовать каррированные лямбды? Для них частичное применение вполне работает. И композицию (комбинирование) двух каррированных лямбд тоже написать не проблема: однострочное выражение.

А кто вам мешает в Kotlin использовать каррированные лямбды? Для них частичное применение вполне работает. И композицию (комбинирование) двух каррированных лямбд тоже написать не проблема: однострочное выражение.

А причем тут карирование?

?? ??

???

PartialFunction про другое

А причем тут карирование?

Ну partial functions - частичное применение? Если да, то как раз каррированием оно и делается.

нет

val foo: PartialFunction[Int, Int] = { case 1 => 2 } функция foo определена только на значении 1

Ааа. PartialFunction - не тотальные функции.

ага

ага

Ну да. В Kotlin when выражение требует, чтобы все варианты были рассмотрены. Правда некоторые могут бросать исключение, но это уже другое. У PartialFunction в Scala есть метод для проверки, определена она на значении, или нет.

Ну да. В Kotlin when выражение требует, чтобы все варианты были рассмотрены. Правда некоторые могут бросать исключение, но это уже другое. У PartialFunction в Scala есть метод для проверки, определена она на значении, или нет.

только в случае если результат when-а где-то используется

только в случае если результат when-а где-то используется

Ну я и говорю про when выражение, а не про конструкцию.

when expression VS when statement

Ну построение отчёт - это по сути функция: (Data, Template) => Report А дальше - это уже pattern matching в чистом виде В котлине не хватает PartialFunction, которые можно комбинировать Так бы можно было описать каждый кейс отдельно и потом в одном месте сделать что то вроде val report: (Data, Template) -> Report = { reportA .orElse(reportB) .orElse(reportC) .andSoOn } Всё отлично расширяется и описывается нормально

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

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

Да и через опциональное значение можно

Да и через опциональное значение можно

С языка сняли

ну да, через ?: будет очень даже идиоматично

ну да, через ?: будет очень даже идиоматично

Через ?: не получится комбинировать функции.

Через ?: не получится комбинировать функции.

так если они будут возвращать опциональное значение, то reportA(x) ?: reportB(x) ?: reportC(x) и так далее

так если они будут возвращать опциональное значение, то reportA(x) ?: reportB(x) ?: reportC(x) и так далее

+

ERROR: S client not available

Всем привет! Вопрос немного (совсем) оффтоп, но я просто не знаю, где спрашивать (может, посоветуете чего). Вопрос следующий - что необходимо при оформлении на дистанционную работу за границу из России?

Всем привет! Вопрос немного (совсем) оффтоп, но я просто не знаю, где спрашивать (может, посоветуете чего). Вопрос следующий - что необходимо при оформлении на дистанционную работу за границу из России?

Сходи в @pofftop, это как-то действительно совсем оффтоп. :)

Всем привет! Вопрос немного (совсем) оффтоп, но я просто не знаю, где спрашивать (может, посоветуете чего). Вопрос следующий - что необходимо при оформлении на дистанционную работу за границу из России?

https://t.me/pogromisty здесь попробуй спросить

понял, спасибо

+

Вот практически 1 в 1 пример из Scala: typealias PartialFunction<A, B> = (A) -> B? infix fun <A, B> PartialFunction<A, B>.orElse(other: PartialFunction<A, B>): PartialFunction<A, B> = { this(it) ?: other(it) } fun main(args: Array<String>) { val isEven: PartialFunction<Int, String> = { if (it % 2 == 0) "$it is even" else null } val isOdd: PartialFunction<Int, String> = { if (it % 2 == 1) "$it is odd" else null } println((1..10).map(isEven orElse isOdd)) } https://www.scala-lang.org/api/2.12.1/scala/PartialFunction.html

тоже пойдёт

Проблема только будет, если тебе надо будет комбинировать PartialFunction<A, B?>

Проблема только будет, если тебе надо будет комбинировать PartialFunction<A, B?>

Да. С точки зрения системы типов PartialFunction<A, B> и PartialFunction<A, B?> не различимы.

Ну чтобы сделать их различимыми надо уже делать через Option. Тогда null и empty станут разными значениями.

https://github.com/JetBrains/kotlin/blob/1.3.0/ChangeLog.md#13-rc

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

Всё вам расскажи… Вы что, сюрпризов не любите? ?

?

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

А когда конфа, не подскажите?

А когда конфа, не подскажите?

4-5 октября, будет трансляция

4-5 октября, будет трансляция

Спасибо!

ээээ... а может мне кто объяснить мотивацию запрета на использовани kotlin.Result как типа возвращаемого значения? =) https://youtrack.jetbrains.com/issue/KT-26659

ээээ... а может мне кто объяснить мотивацию запрета на использовани kotlin.Result как типа возвращаемого значения? =) https://youtrack.jetbrains.com/issue/KT-26659

Чтобы компилятор мог безопасно возвращать его в корутинах?..

непонятно ?

непонятно ?

Чтобы никак не получилось Result<Result<...>>, это сломает инлайновость

ЭЭЭ... а зачем нужен результ который вернуть нельзя? о_О

Можно, но только руками компилятора

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

Ну, имеет, но нельзя :)

мля ?

Почему бы не спросить об этом в тикете?

А потом тут рассказать почему же

Хороший вопрос, пойду порефлексирую

Здесь описано почему: https://github.com/Kotlin/KEEP/blob/result-rename/proposals/stdlib/result.md

Спс