пропаганд котлина вроде запрещена среди джуниоров, закон яровой или что-то такое

Что-то там про гомоиконность? Ты с clojure не попутал?

о, на гомоиконность набрасывают

приятно

раз набрасывают, значит знают

ну или хотя бы слышали

Я активный открытый гомоиконист!

а бывают пасивные?

и закрытые?

бывают латентные

Что эт за слово такое

можно же не читать 500+ сообщений?

По вкусу, там мини срач

я пролистал. опять доказывали что типы это хорошо и про то почему скалистам не нравится json как мапа :)

ну и чота там про груви всплывало

Жаль тут Баруха нет, а то бы про груви было больше

достаточно про груви

Более чем?

Без "?"

давайте снова про скалу и церковь

Ох.

Две вещи греют меня в этом мире, горящая церковь и успешная компиляция.

Так?

(б)Ох!

* успешное прохождение тестов

которых нет, как и бога ?

Как же без тестов

которых нет, как и бога ?

Шутки на трешку

лет?

Это если коду нет 18ти

16ти

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

уровень шуточек опускается до лепрочки =)

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

хотя конечно шутки про варга и церковь никогда не надоедают.

хотя конечно шутки про варга и церковь никогда не надоедают.

?

http://rustelegraph.ru/photo/all/19852.jpg

Друзья, важно ваше мнение, вот есть код, хочется ли вам в нём что-то улучшить, что именно, в каком месте, что в текущем коде режет глаз?https://gist.github.com/xnull/bbcf46bfa72e3e403654e3fdf13545e6

хочется поговорить за дизайн кода в Фу стиле )

в этом коде мне режет глаз класс Business Logic

val dao = createDaoImpl() dependency injection надо вместо

ну это да, само собой

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

в этом коде мне режет глаз класс Business Logic

чем именно?

плюсую за публичные методы

Business Logic - это вообще что с точки зрения предметной области? В ООП важна абстракция, какую сущность олицетворяет класс BusinessLogic?

то есть имя класса?

да

val dao = createDaoImpl() dependency injection надо вместо

В скале до сих пор нет нормального идеоматичного DI. Боль и страдание.

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

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

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

метод foo не хочется его как-то переделать?

да и вообще класс BusinessLogic

ну кстати волне себе нормальный код. кому то надо не функторы хуюнкторы, а ехать =)

))

В скале до сих пор нет нормального идеоматичного DI. Боль и страдание.

Не знаю; у нас play, то что там внутри есть то и используем. и не страдаем :)

метод foo не хочется его как-то переделать?

ну если придираться, то хочется. я, возможно, сильно впрягаю за DDD, но идентификатор сущности Long - не слишком Verbose, стоит выделить для этого отдельный ValueObject. достаёшь некую entity, а публикуешь её в EventBus. нормально только в случае, если твоя Entity это какой-то эвент, но это какой-то странный эвент сорсинг получается

мы когда то вот так делали https://github.com/unicorndevru/images/tree/master/src/main/scala/images

ну да, и Entity string, та же беда, в OOPStyle не место одержимости примитивами

Я к чему это про foo метод разговор завёл, вот в скале есть функторы хуюнкторы и в правильных книжках и мануалах нас учат, что надо пользоваться функциями везде и тогда жизнь наладится. В данном коде, если писать по каноничному в ФП (Фу - можно я буду называть это Фу стилем? ничего не могу с собой поделать), то должно на мой взгляд получиться как-то так (в псевдокоде): val findEntity = findEntityFunction(entityId) val publish = publishMessageFunction(message: String) def foo(entityId) = findEntity then publish ведь так?

какой тип у findEntityFunction?

ну добавлять Function к названию функции это redundant

ERROR: S client not available

по идее это должно быть чтото типа def findEntityFunction(dao: Dao)(id: Long): String = dao.findById(id);

я добавил чтобы понятно было из названия

а у publishMessageFunction какой тип?

def publishMessageFunction(eventBus: EventBus)(message: String): Unit = eventBus.publish(message)

def findEntity: String => String = ??? def publishMessage: String => Unit = ??? def findAndPublish: String => Unit = findEntity andThen publishMessage

да, именно! но вот если я начну писать код в таком стиле боюсь.... просто боюсь)

слишком много косвенности на ровном месте получается

ну в реальной жизни у тебя будет def findEntity: String => Future[Option[String]]

так что так ты писать все равно не будешь )

и def publishMessage: String => Future[Unit]

Вот такой вопрос кстати, кто в scala проектах, пользуется "паттерном" DAO, и если вы им не пользуетесь, то как у вас организован код работы с бд?

выше найдите мою ссылку на гитхаб

прямо немножко выше

и там про дао или про Фу стиль?

что такое DAO и чем это отличается от трейта с методами или Free DSL ?

про всякое там короче

просто как пример

что такое DAO и чем это отличается от трейта с методами или Free DSL ?

https://ru.wikipedia.org/wiki/Data_Access_Object

ад и погибель

это объект, который предоставляет абстрактный интерфейс

все :)

нужен интерфейс - сделай его

def findEntity: String => String = ??? def publishMessage: String => Unit = ??? def findAndPublish: String => Unit = findEntity andThen publishMessage

Дык вот я про чо собственно, findEntity в данном случае выглядит красиво до тех пор пока не встает вопрос - как туда подпихнуть dao объект? В общем случае это будет нагромождение кода в виде: publishMessageFunction(eventBus: EventBus)(message: String)то есть мне в каждую функцию надо передавать "инфраструктурные" штуки от которых она завистит или с помощью которых она общается с внешним миром

в данном случае eventBus и прочие дао и сервисы будут "путешествовать" по сигнатурам наших методов в системе

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

в этом случае class x(infrastructureObj: SomeObj, infrastructureObj2: SomeObj) {def foo() = infrastructureObj.toDoSomething()}выглядит как выход

но мы опять скатываемся в ооп и оборачиваем наши функции объектами

вобщем для меня остается загадкой как писать без многих НО по настоящему в фу стиле

вобщем для меня остается загадкой как писать без многих НО по настоящему в фу стиле

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

для начала не называть ФП фу стилем

реально слух режет

никто не заставляетй писать только на функциях