нет, какой баг!

там жаваскрипт!

в жаваскрипте нет багов

попробуй такой же трюк с Си

просто бабель настроен не правильно

в жаваскрипте нет багов

Т.е. СПЛОШНОЙ БАГ...

просто бабель настроен не правильно

...ну ладно

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

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

если кто переживает за любимый пхп - там то же самое)))

тут дело не в сравнении

тут дело в понятии Infinity

ммм тебя смущает что infinity === infinity?

меня смущает поводение флоата на числе 1.7976931348623158e+308

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

но превращается в макс-флоат

из-за этого 1.7976931348623157e+308 === 1.7976931348623158e+308 > true

точнее даже это поведение интерпретатора

точнее даже это поведение интерпретатора

наверное дело в экспоненциальной записи, и там есть округление когда интерпретатор с ними работает вот тут http://www.exploringbinary.com/floating-point-converter/ если перевести в десятичные эти два числа 1.7976931348623157e+308 === 1.7976931348623158e+308 то они будут одинаковы)

почему?

почему именно с этим числом проблема?

предыдущие два нормально, и следующее нормально, а вот это - особенное

1.7976931348623157e+308 sign field | exponent field | significand field 0 11111111110 1111111111111111111111111111111111111111111111111111 1.7976931348623158e308 sign field | exponent field | significand field 0 11111111110 1111111111111111111111111111111111111111111111111111 в бинарном виде )))

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

перепроверить но я пасс

первое число - максимум, во втором переполнение

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

ох я упоролся(

так а если у меня например все действия на запись сделаны по нормальнйо архитектуре слоистой с ооп и всеми плюшками, а для участков где мне надо чтения я просто хреначу sql с нужными параметрами...это ведь тоже может считаться CQRS на минималках?)

“CQRS на минималках» - это ты хорошо сформулировал) присоединяюсь к вопросу

сам по себе cqrs так себе относится к слоистой архитектуре, ооп и прочим умным словам) из описания, чёт не видно "на минималках".

а вот почему у любителей обмазаться шинами не cqrs - любопытно) ну т.е. чем "в лоб" отличается от шины для команд/событий и запросов, которые дружат с рид модельками)

сам по себе cqrs так себе относится к слоистой архитектуре, ооп и прочим умным словам) из описания, чёт не видно "на минималках".

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

“CQRS на минималках» - это ты хорошо сформулировал) присоединяюсь к вопросу

вполне себе

главное условие для CQRS - разделение операций чтения и записи

это как развитие идей CQS

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

нет, CQRS подразумевает ВОЗМОЖНОСТЬ разделения хранилища, оно его не требует.

если ты пишешь и читаешь из одной СУБД но на уровне приложения за это отвечают разные интерфейсы (может один класс просто имплементящий два интерфейса), если клиентский код зависит от разных API для чтения и записи, и API на чтение не пораждает сайд эффектов (это как следствие CQS) - то это вполне себе CQRS и даже не на минималках

главное условие для CQRS - разделение операций чтения и записи

окей, а чем тогда все же он от cqs в этом плане отличается?

CQS про отдельные методы

CQRS про отдельные интерфейсы)

ага, спасибо

довольно зыбко на самом деле)

почему?

но это вопросы к создателям

ну имхо сигнатура метода - уже нечто, стремящееся к интерфейсу

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

но я основную идею понял

это "лишь бы придолбаться"

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

ну по сути разница только в организации кода

если с такой точки зрения рассматривать

ммм.... в масштабах скорее.... в CQS у тебя разделение методов по типам но они могут быть в пределах одного интерфейса

и под интерфейсом я тут более общее подразумеваю - некое API програмное

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

ну по сути разница только в организации кода

ну в целом да

соблюдение CQS в целом позволяет тебе упростить тестирование

и в целом клиентский код

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

это тоже уловил)

cqrs = cqs на стероидах когда только вникал в эти концепции - разницы вообще не видел, кроме одной буквы)

как следствие того что CQRS (как архитектурный прием) является развитием идеи CQS (как принцип), ты не можешь на нем реализовать такую простую вещь как pop для стэка

а вот почему у любителей обмазаться шинами не cqrs - любопытно) ну т.е. чем "в лоб" отличается от шины для команд/событий и запросов, которые дружат с рид модельками)

.

как следствие того что CQRS (как архитектурный прием) является развитием идеи CQS (как принцип), ты не можешь на нем реализовать такую простую вещь как pop для стэка

то есть методы на изменение не могут вообще никакой информации вернуть?

а вот почему у любителей обмазаться шинами не cqrs - любопытно) ну т.е. чем "в лоб" отличается от шины для команд/событий и запросов, которые дружат с рид модельками)

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

а вот почему у любителей обмазаться шинами не cqrs - любопытно) ну т.е. чем "в лоб" отличается от шины для команд/событий и запросов, которые дружат с рид модельками)

тем что это "сверху"? ну то есть "шины" же решают проблему коммуникаций, они к CQRS никакого отношения не имеют.

но и не конфликтуют никоим образом. Это разные "паттерны" и решают они свои задачи

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

"вместо" - не очень подходящее слово)

то есть методы на изменение не могут вообще никакой информации вернуть?

вообще по хорошему не должны)

"вместо" - не очень подходящее слово)

лень расписывать)

лень расписывать)

а я не понял наброса :(

тем что это "сверху"? ну то есть "шины" же решают проблему коммуникаций, они к CQRS никакого отношения не имеют.

пасиб, в такой формулировке, понятно)

а я не понял наброса :(

у тебя шины для общения ж вроде разных процессов, нет?

угу

вообще по хорошему не должны)

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

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

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

какие заголовки?

ты о чем?

мне кажется ты что-то не так понял

ну то есть ты сейчас про UI

про http

да

а я про "дернуть функцию/метод/процедуру"

аа

ок, понял

такое API)

ну и повторюсь - CQS это "принцип", не универсальный принцип, просто он позволяет делать более гибкие штуки.

ты никак не сможешь его соблюдать на 100%, опять же пример с pop у стэка

опять cqrs

опять монады

а я б послушал про монады

да!

Rx считается cqrs?

а я б послушал про монады

че там слушать

Rx считается cqrs?

мм.... Rx же про стримы событий, нет?

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

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

мм.... Rx же про стримы событий, нет?

да

да

в моем представлении Rx про то что кто-то может запаблишить событие, и ты можешь с событиями работать как с коллекциями.