Там я не смог увеличить

Блин, вот как посмотреть стикеры перед отправкой?

жмешь и держишь

в вебверсии это не работает, говорят

жмешь и держишь

спасибо)

таки да, в вебе не работает

Если бы вы увидели такой класс, что бы вы подумали? :) object Behavior { type In[Command[_], State, Response] = (Command[Response], State) type Out[Event, Response] = (Seq[Event], Response) } case class Behavior[Command[_], State, Event]( aggregateName: String, eventTag: EventTag[Event], identityExtractor: Command[_] => String, commandHandler: Behavior.In[Command, State, ?] ~> Behavior.Out[Event, ?], initialState: State, eventProjector: (State, Event) => State )

пахнет как Akka.typed

типа "ты мне команду вот такую, а я тебе ответ определенного типа"

Близко, но насколько я знаю в Akka Typed еще не решили как будет выглядеть akka-persistence :)

Ну неплохой основной класс для описания бихейвиоров)

мне, если честно, больше нравилась идея за TypedActors, с Akka Typed я толком пока не разобрался. То есть понятно, почему они решили отойти от typed actors, но выглядит пока страшновато, как мне кажется

ООП-шникам может взрывать голову такой код ))

Видно опыт хаскеля у писателя

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

начиная с такой мелочи как непоследовательность упоминания типов

Mikhail продолжай )

Command[_], State, Response - в то время, как следом идет упоминание их в другом порядке

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

и тут уже непоняточка - как Command связан со State ?

Mikhail тут больше с точки зрения каррирования конструктора такой порядок

Command валидируется относительно State

на выходе у меня помимо респонза отданного (я так думаю) командом - добавляется Event - и вот вобще непонятно, почему он никак больше ни с чем не связан, да и зачем мне их целая авоська этих ивентов

Одна комманда может породить несколько событий

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

а если сказать что это в контексте eventsourcing?

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

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

моя совсем запуталась

и то и другое :)

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

да

эффект на стейт

но тогда не очень понятно, почему команд не связан баундом с ивентом

Command[Event, Response]

тогда связь была бы более очевидна

потому что event это внутрення кухня стейта

После запуска этого поведения на выходе ты получаешь Command ~> Future

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

Command это считай Free DSL

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

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

значит это будет захардкожено - это вынесено в типа поведения

у тебя есть аггрегат, стейт (State) которого пересодзается из событий (Event)

Но я не спорю ни в коем случае ) наоборот, критика - это супер

подумал бы что тут Луковая Архитектура

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

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

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

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

даже со своим после того как пару лет оно где-то поработает)

в целом по типам кстати напоминает frp-шный foldp

а еще неплохо когда для классов которые на выходе выдают какой-то Response - указывать баунд для Request

ну или вообще заявка на катаморфизм некий

потому как вроде респонзов без реквестов не бывает)

Тогда сигнатура Command[Request, Response, Event] - сказала бы примерно то, что было в ответе

Mikhail, [10 окт. 2016 г., 16:27]: или респонз это выход команды, а ивент фоновая побочка команды? Denis Mikhaylov, [10 окт. 2016 г., 16:28]: да эффект на стейт

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

Ну так этот Behavior и есть все необходимое чтобы создать интерпретатор Command ~> Future который бы работал под капотом на Akka. Алгебра это уже то как его исопльзовать

ERROR: S client not available

Так команда это и есть запрос

а вот это я уже называю "плохо спроектировано"

спроектировано может и норм, просто названия у типов немного запутывают

sealed trait AccountOp[R] case class OpenAccount(accountId: AccountId) extends AccountOp[Rejection Xor Done] можно рассматривать как trait AccountOp[F[_]] { def openAccount(accountId: AccountId): F[Rejection Xor Done] }

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

Запрос всегда определяет вид респонза

нет

ну понятно, free-фикация

как нет? )

вот тебе простой пример с хттп

возьми твиттер апи

на вход ты подаешь post params, а на выходе можешь получить как xml , так и json

request не меняется, респонз меняется

XML Xor JSON

это один из самых наглядных и базовых примеров

Грубо говоря

нондетерминизм это всегда приятно

XML Xo JSON - в корне неправильно)

ибо xml, json - в данном конкретном случае - есть вид сериализации

ну так это разные уровни абстракции

HttpRequest всегда даст HttpResponse

type SerializedResponse = XML \/ Json ?

да зачем это делать то

вы шо

это применяется на выходе

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

и другой код работать с этим не будет

а вы для него новый уровень абстракции хотите нагородить)