просто потому что кто-то забыл или потому что идут вложенные вызовы... а если Future[\/] начинается вообще угар и содомия

тогда уже проще Task взять

https://github.com/functional-streams-for-scala/fs2

да, грядет RC1 :)

? таски конечно чертвоски удобные

ага... все эти стримы очень удобные и всё такое... но часто вам в реальных бизнес задачах нужно перегонять данные с одной коллекции в другую с процессингом? ведь надо признаться что почти все пишут REST API к базе данных с прослойкой бизнес логики

> REST API к базе данных https://github.com/stliang/functional-microservice-example

И вы таки хотите сказать что вот это: https://github.com/stliang/functional-microservice-example/blob/master/core/src/main/scala/ToDo.scala не воплощение пиздеца?

да вроде норм

Ну ок...

вас смутила фамилия швейцарского математика?

\/,-\/,\/- смайлики, смайлики светлого мая привет (с)

с чего бы начать... наверное с того что за такие название переменных принято пальцы ломать def list: ToDoK[List[Item]] = for { a <- config b <- a.repository.list.liftKleisli } yield b

названия локальны и так понятно что они такое, так что норм

Вот представьте что человек только пришел в язык, а вы ему вот это показываете и говорите ну чё? как?

а, запятые не по уставу

а если человек до этого ещ

я надеялся что там слово сложится в столбик

ё не программировал то вообще

for { s <- config h <- currentTime u <- randomUUID k <- currentTimeMillis a <- a.repository.create(i).liftKleisli } yield a как-то так :)

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

Имена переменных нужны когда вы через пол года чините баг в проекте

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

for { s <- config h <- currentTime u <- randomUUID k <- currentTimeMillis a <- a.repository.create(i).liftKleisli } yield a как-то так :)

дык хоть через 5 лет, h=currentTime понятно же и так. пока yield d jlye cnhjxre dc` jr

водну строчку все ок

Ну что вы в самом деле как будто у нас тут фортран с коболом. Имя переменной это всего-лишь имя. Особенно когда у тебя мощная система типов и IDE.

во во

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

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

Недавно ковырял word2vec гугловский. Он на сях, там процедуры на 200 строк, реюз структур и переменных с называниями i, j, d, M. Первые 15 мин было не комфортно, но потом нормально пошло. В момент перехода от «ничего не понятно» в «ах вот оно что» я подумал что круто, когда человек понимает что он делает. Стройная мысль остается стройной мыслью, даже если она выражена в запутанном коде. Гораздо хуже, когда джависты которые ничерта не понимают что они делают лепят фабрики-стратегии в языке, где есть замыкания и паттерн-матчинг. Обычно у этих джавистов очень подробные названия переменных.

http://docs.spring.io/spring-framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

Но согласитесь что было бы проще, если бы имена переменных в этом Cи коде несли бы смысл? вы бы с экономили 15 минут... ну и это у вас вышло 15 минут, а у другого человека могло уйти много часов... Про джавистов... да это большая беда мне несколько раз приходилось работать с такими людьми... на собеседовании они блистали знаниями паттернов и всего прочего... а бизнес задачи решить были не способны

а скалисты были способны?

а джаваскриптисты способны? Вопрос такой: Программисты на каком языке способны решать бизнес задачи?

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

UML

))

ахахха

хороша шутка

кто нибудь проходил? https://www.scala-exercises.org/shapeless/polymorphic_function_values

о кстати да

надо бы глянуть

Еще одна чудо трава :)

эта трава уже и в компилятор прорастает https://github.com/scala/scala/pull/5310 ;)

Про фабрики очень в цель :-( лучше переменные i,j чем фабрика фабрик фабричных методов

как реализовать паттерн Producer\Consumer если у нас очередь иммутабельна?

в функциональном стиле

дался вам этот "функциональный стиль" если задача явно лучше решается по-старинке, то так и стоит делать

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

А есть кто пользовался https://github.com/magro/kryo-serializers

я как-то давно, вроде все было гладко

У меня проблема с тем что падает сериализация Value Class

Падает вполне логичным class cast, но как это победить я не что-то не могу придумать

Тоесть у меня есть case class EntityId(value: String) extends AnyVal И вот при сериализации крио выдаёт что не может скастить String в EntityId

нужно наверное писать custom serializer

падает наверное при десериализации?

btw в скале крио рекомендуют использовать в связке с https://github.com/twitter/chill , там уже есть сериализаторы для многих случаев

Хорошо, посмотрю в эту сторону, как только код начнет снова компилироваться

Эх были бы сериализаторы которые бы собирали статистику предлагали бы новую версию с хафман энкодингом

С такими желания можно далеко зайти )

Когда-нибудь машины будут брейнстормить глубокими нейронными сетками задачи и потом писать на аналоге Coq сами код. А на джава/ооп артефакты из прошлого будут смотреть как мы щас на шаманов или египетских жрецов.

но джава программисты все равно останутся, как щас христианство.

Интересно зачем машинам Coq, это ж для людей

Аналог в том плане, что тоже предлагает экспоненциальное количество вариантов а нейронка выбирает что-то из них

но джава программисты все равно останутся, как щас христианство.

хорошая шутка

trait AsFunc { def as[O]: Option[O] } class DialogContext { private val variables = collection.mutable.HashMap[String, Any]() def apply[T](name:String):AsFunc = { val value = variables.get(name) new {} with AsFunc { def as[O]: Option[O] = { value match { case Some(v) => Option(v.asInstanceOf[O]) case None => None } } } } def update[T](name:String, value:T): Unit = { variables(name) = value } } Есть такой код, и есть еще такой: val context = new DialogContext() context("foo") = "bar" val bar = context("foo").as[Int] println(bar) Вместо None возвращается Some("bar") , почему-то case Some(v) => Option(v.asInstanceOf[O]) не хочет кастовать

ERROR: S client not available

дальше еще интереснее: val bar:Option[Int] = context("foo").as[Int] в баре почему-то хранится строка, хотя тип явно указан Int

лол, что за бред

Ну это же приведение типа, а не конвертация.

Должно быть вообще ClassCastException.

должно, но нету

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

ппц ну дела конечно

Выполнил твой код в репле.

МДАААА классКаст появился только когда я захотел сложить строку с числом println(bar.get + 5)

Есть исключение.

а у меня нет, куда копать?

наверно туда откуда as взялся, хз что это за DialogContext

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

Для начала надо поставить линукс или купить мак :)

Троллмод офф

sbt console

или если стоит то просто scala

линукс есть, но переключаться сейчас на него не хочется)

А всё что стоит на винде - это IDEA

Всё, больше ничего

а у меня нет, куда копать?

Вообще я бы копал в отказ от класскастинга. Я бы сделал что-нибудь типа sealed trait DialogContextItem object DialogContextItem { case class Text(value: String) extends DialogContextItem case class Numeric(value: Double) extends DialogContextItem case class Timestamp(value: Long) extends DialogContextItem case object Empty extends DialogContextItem }

наверно туда откуда as взялся, хз что это за DialogContext

Там чуть чуть повыше есть код с диалогКонтекстом

Вообще я бы копал в отказ от класскастинга. Я бы сделал что-нибудь типа sealed trait DialogContextItem object DialogContextItem { case class Text(value: String) extends DialogContextItem case class Numeric(value: Double) extends DialogContextItem case class Timestamp(value: Long) extends DialogContextItem case object Empty extends DialogContextItem }

Должна быть возможность хранить объекты разных типов, на все не напишешь такие конвертеры

Это будет неудобно

Должна быть возможность хранить объекты разных типов, на все не напишешь такие конвертеры

Сколько типов есть сейчас?

Эм... может я туплю, но хранить в базовых типа Any нельзя?

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

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

Ну тогда сделай множество открытым.

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

Это как?

Храни в JSON :)