Вот только Constraint Assertion из NUnit куда более юзабельны. Fluent Assertion способна описать assertion как входной параметр теста? А вот NUnit позволяет это сделать довольно красиво.
Решение сам и написал. Перечисления в C# - это именно классические перечисления, просто константы на уровне компилятора. В Java это совершенно иная конструкция. Использование enum в Java стиле спорная вещь, по сути это перечисление, что возвращает данные совершенно иного типа. Ну и как бы слегка нарушает принцип единой ответственности.
Ковариантность - это такой неплохой способ стрелять себе в ногу. Зачем? Пример приведён чисто академический. В реальной жизни ООП на таком уровне где-то используется? Лучше уж жить на фабриках и тогда ковариантность вообще не потребуется.
Смотри что такое delegate в C#
Собственно мне наоборот не нравится данная фича. Так как олпять же вносит энтропию в проект. Да, слегка уменьшает объёмы кода, но при этом в Java есть куча всего, что прям увеличивает объёмы кода в неимоверных масштабах. Ну и опять же, делегаты убирают кучу необходимых мест для использования анонимных реализаций интерфейсов.
К железке лютый атас и колхоз. Выглядит прям всё крайне ужасно.
К переводу, лютый атас и даже не колхоз, гуглтранслейт? Автор перевода, просвяти, что такое USB-сигнал? Как можно было USB keyboard device превратить в USB-сигнал?
По первому же примеру кода стало понятно, либо автор вообще не понимает как же пишется многопоточный код и что же делает volatile, либо специально решил поднакинуть на вентилятор.
Эмуляция объекта работает однозначно медленее, чем объект на базе прототипа. А по поводу хуков я согласен с 0м сообщением.
Хуки сделали для того, чтобы ещё снизить порог вхождения, но низкий порог вхождения чреват тем, что появляется куча народу "знающих" как надо программировать.
Класс даёт очень хорошие возможности по инкапсуляции. В итоге всё в одном месте. Функциональный же подход привёл лишь к тому, что постоянно есть куча функций, а когда их становится сотни и более разбираться становится ну очень не просто.
Да и хуки привели лишь к тому, что цикл работы компонента стал ещё менее понятен и куда хуже поддаётся контролю.
В итоге сделать прототипчик проще, заставить его хорошо работать стало куда сложнее.
Вместо резиновой хорошие складные клавиатуры, взял одну такую, удобно, она действительно мало места занимает, в отличии от рулона из резиновой.
А у русских клонов ZX Spectrum были механические клавиши, но крайне посредственного качества, плёночные от 128кб версии жили хорошо, а вот эта механика умирала на ура. По началу они работали нормально, а потом надо было жать кнопки со всей дури.
Но для обработки SLA моделей требуется гораздо больше места. У FDM отодрал от стола и окей. У SLA надо достать, промыть, надо досушить в отдельном устройстве, да ещё ничего по пути не забрызгать, да и вентиляцию хорошую надо. У FDM если печатать разве что ABS пластиками, ну или если SBS пережарить.
И чем он хуже редакса? Тем что не шарашит по всем компонентам на перерисовку в случае изменения данных? Тем что позволяет хранить любые данные, в том числе и инстансы классов в отличие от редакса? Ну и видимо тем, что весь необходимый код лежит в одном месте, а не в куче файлов раскиданных по всему проекту. Ну и видимо ещё тем, что эффектор код легко найти по зависимостям в коде, а редакс надо искать по магическим строковым константам? Ах да, может эффектор ещё хуже потому, что не требует дополнительных библиотек для реализации сайд эффектов?
На сях бесполезно. Без асма делать нечего. Даже в 2D. При этом он очень прост. Я в 3D на нем не лез, чутка в демосцену. В основном занимался геймдевом. И все же очень упоротой оптимизации, код генерации, предварительных расчётов делать там нечего. Все 3D строится строго на предсгенерированных таблицах для тригонометрии. Вылизанных до основания функциях умножения и деления.
Это проблема API и ещё какая. Если уж инструмент не предназначен для чего либо, то и желательно как-то ограничить API. Опять же документация и внятное описание для решения каких проблем инструмент подходит. Топором тоже можно забить гвоздь, но ведь молотком удобнее.
Видимо понимает и ещё как. Делается отдельный сервис хранилище, отвечающий за конкретные данные. И пользуйтесь им на здоровье, в совокупности c RxJS вообще будет отличное решение. Да при этом данное решение ещё и легко тестируется.
Вот только Constraint Assertion из NUnit куда более юзабельны. Fluent Assertion способна описать assertion как входной параметр теста? А вот NUnit позволяет это сделать довольно красиво.
Решение сам и написал. Перечисления в C# - это именно классические перечисления, просто константы на уровне компилятора. В Java это совершенно иная конструкция. Использование enum в Java стиле спорная вещь, по сути это перечисление, что возвращает данные совершенно иного типа. Ну и как бы слегка нарушает принцип единой ответственности.
Ковариантность - это такой неплохой способ стрелять себе в ногу. Зачем? Пример приведён чисто академический. В реальной жизни ООП на таком уровне где-то используется? Лучше уж жить на фабриках и тогда ковариантность вообще не потребуется.
Смотри что такое delegate в C#
Собственно мне наоборот не нравится данная фича. Так как олпять же вносит энтропию в проект. Да, слегка уменьшает объёмы кода, но при этом в Java есть куча всего, что прям увеличивает объёмы кода в неимоверных масштабах. Ну и опять же, делегаты убирают кучу необходимых мест для использования анонимных реализаций интерфейсов.
Но как обычно. Слабая связность? А зачем. Отделение логики от отображения? Никому не надо. И собственно всё в том же духе.
К железке лютый атас и колхоз. Выглядит прям всё крайне ужасно.
К переводу, лютый атас и даже не колхоз, гуглтранслейт? Автор перевода, просвяти, что такое USB-сигнал? Как можно было USB keyboard device превратить в USB-сигнал?
По первому же примеру кода стало понятно, либо автор вообще не понимает как же пишется многопоточный код и что же делает volatile, либо специально решил поднакинуть на вентилятор.
Одно не понял из статьи, в 2020м обнаружили у него вещества для производства взрывчатки. А какого он на свободе?
Хм, уже название исполняемого файла спорное. Точно такое же название и у компилятора в js.
Жрать колеса и вырабатывать устойчивость. Да, шикарный план. А потом кайфовать ещё с глючащей вегетативкой. Вообще план шикарен.
Стреляем себе в ногу изначальной ошибкой архитектуры, потому вытаскиваем пулю из ноги выстрелом в голову. Гениально.
Эмуляция объекта работает однозначно медленее, чем объект на базе прототипа. А по поводу хуков я согласен с 0м сообщением.
Хуки сделали для того, чтобы ещё снизить порог вхождения, но низкий порог вхождения чреват тем, что появляется куча народу "знающих" как надо программировать.
Класс даёт очень хорошие возможности по инкапсуляции. В итоге всё в одном месте. Функциональный же подход привёл лишь к тому, что постоянно есть куча функций, а когда их становится сотни и более разбираться становится ну очень не просто.
Да и хуки привели лишь к тому, что цикл работы компонента стал ещё менее понятен и куда хуже поддаётся контролю.
В итоге сделать прототипчик проще, заставить его хорошо работать стало куда сложнее.
Вместо резиновой хорошие складные клавиатуры, взял одну такую, удобно, она действительно мало места занимает, в отличии от рулона из резиновой.
А у русских клонов ZX Spectrum были механические клавиши, но крайне посредственного качества, плёночные от 128кб версии жили хорошо, а вот эта механика умирала на ура. По началу они работали нормально, а потом надо было жать кнопки со всей дури.
Не?
Но для обработки SLA моделей требуется гораздо больше места. У FDM отодрал от стола и окей. У SLA надо достать, промыть, надо досушить в отдельном устройстве, да ещё ничего по пути не забрызгать, да и вентиляцию хорошую надо. У FDM если печатать разве что ABS пластиками, ну или если SBS пережарить.
Лет через 10 ждём метеостанции на базе топовых десктопов.
Я понимаю, но цена, энергопотребление, нагрев опять же, датчики надо выносить в отдельный корпус.
И чем он хуже редакса? Тем что не шарашит по всем компонентам на перерисовку в случае изменения данных? Тем что позволяет хранить любые данные, в том числе и инстансы классов в отличие от редакса? Ну и видимо тем, что весь необходимый код лежит в одном месте, а не в куче файлов раскиданных по всему проекту. Ну и видимо ещё тем, что эффектор код легко найти по зависимостям в коде, а редакс надо искать по магическим строковым константам? Ах да, может эффектор ещё хуже потому, что не требует дополнительных библиотек для реализации сайд эффектов?
А где упоминания хотя-бы о Effector, MST и классику RxJS. А упоминание useState уже показатель, что статью дальше читать не стоит.
Постоянные отвалы по блутусу, спасибо, не надо.
На сях бесполезно. Без асма делать нечего. Даже в 2D. При этом он очень прост. Я в 3D на нем не лез, чутка в демосцену. В основном занимался геймдевом. И все же очень упоротой оптимизации, код генерации, предварительных расчётов делать там нечего. Все 3D строится строго на предсгенерированных таблицах для тригонометрии. Вылизанных до основания функциях умножения и деления.
Явный троллинг
Ещё более явный троллинг
Опять же сродни троллинга
Это проблема API и ещё какая. Если уж инструмент не предназначен для чего либо, то и желательно как-то ограничить API. Опять же документация и внятное описание для решения каких проблем инструмент подходит. Топором тоже можно забить гвоздь, но ведь молотком удобнее.
Видимо понимает и ещё как. Делается отдельный сервис хранилище, отвечающий за конкретные данные. И пользуйтесь им на здоровье, в совокупности c RxJS вообще будет отличное решение. Да при этом данное решение ещё и легко тестируется.
В этом смысле memo, ну да, тут согласен. Что-то не совсем правильно понял вышенаписанное.