Вообще, тут все (как всегда) упирается в IoC. По сути, у нас есть два варианта: либо прямая глобальная зависимость, либо возвращение сценария для обработки внешним интерпретатором.
То есть мы либо напрямую тыкаем палочкой глобальное состояние (например, берем и изменяем позицию мячика в нашем арканоиде). Либо мы возвращаем некую чистую структуру, которую мы можем взять и рассмотреть, и которая потом запихивается в грязный интерпретатор, который уже двигает наши шарики.
Часто совмещают оба подхода: состояние мы читаем напрямую из read-only глобального контекста, а вместо прямых мутаций возвращаем описания мутаций. Ну это очевидный хороший вариант.
Мой поинт в том, что в подавляющем большинстве случаев следует выбирать глобальную зависимость и прямые мутации. (Чтобы не было лапши, состояние нужно хранить централизовано, юнидирекшнл флоу там, все такое прочее - ну это в 2k20 даже жс-макаке понятно, считай уже закрытая проблема.)
Потому что чистота (в таком виде, как мы ее тут обсуждаем) - это на самом деле совсем не про качество кода, минимизацию лапши и т.п. Это исключительно про интроспекцию. Если нам нужно (необходимо, обязательно) как-то анализировать наши потоки данных и строить по ним какие-то метаданные - ок, мы пилим чистую архитектуру. Вопрос тут не в сайд-эффектах как таковых, а именно в данных: либо они у нас идут неявно, лио мы их делаем явными. Сайд-эффекты как таковые тут вообще не первичны. Отличие между вызовом какого-нибудь условного BallManager.moveBall(...) и возвращением структуры {"event_type": "move_ball", ...} исключительно и только в том, что последнее мы можем визуализировать\сохранить в лог\среплеить на других данных\етк. Соответственно, если перед нами не стоит такой задачи или если наш стек технически не предоставляет возможности ее реализовать, то это все - карго-культ и мы занимаемся хуйней.
tl;dr: манатки ненужны, сосите хуй.
То есть мы либо напрямую тыкаем палочкой глобальное состояние (например, берем и изменяем позицию мячика в нашем арканоиде). Либо мы возвращаем некую чистую структуру, которую мы можем взять и рассмотреть, и которая потом запихивается в грязный интерпретатор, который уже двигает наши шарики.
Часто совмещают оба подхода: состояние мы читаем напрямую из read-only глобального контекста, а вместо прямых мутаций возвращаем описания мутаций. Ну это очевидный хороший вариант.
Мой поинт в том, что в подавляющем большинстве случаев следует выбирать глобальную зависимость и прямые мутации. (Чтобы не было лапши, состояние нужно хранить централизовано, юнидирекшнл флоу там, все такое прочее - ну это в 2k20 даже жс-макаке понятно, считай уже закрытая проблема.)
Потому что чистота (в таком виде, как мы ее тут обсуждаем) - это на самом деле совсем не про качество кода, минимизацию лапши и т.п. Это исключительно про интроспекцию. Если нам нужно (необходимо, обязательно) как-то анализировать наши потоки данных и строить по ним какие-то метаданные - ок, мы пилим чистую архитектуру. Вопрос тут не в сайд-эффектах как таковых, а именно в данных: либо они у нас идут неявно, лио мы их делаем явными. Сайд-эффекты как таковые тут вообще не первичны. Отличие между вызовом какого-нибудь условного BallManager.moveBall(...) и возвращением структуры {"event_type": "move_ball", ...} исключительно и только в том, что последнее мы можем визуализировать\сохранить в лог\среплеить на других данных\етк. Соответственно, если перед нами не стоит такой задачи или если наш стек технически не предоставляет возможности ее реализовать, то это все - карго-культ и мы занимаемся хуйней.
tl;dr: манатки ненужны, сосите хуй.
Олды тут?
>Нахуй мне ваша чистота на практике?
Все равно что спросить "Зачем мне нужен хлеб, если я и сырым зерном не плохо питаюсь?".
Ну пиши свой арканоид так, раз тебе так больше нравится. Только потом не плачься, что для добавления новой фичи придется пилить арканоид 2, ибо посмотрев на код первого, ты скажешь: "ну его нахуй, проще переписать".
Привет, Егор. Как твой некрокраси?
Нечего сказать по теме -> уебывай нахуй, обоссанное быдло.
По большому счету, то же самое можно адресовать и тебе. Я предлагаю на обсуждение вполне конкретный технический вопрос, а в ответ вместо контраргументов получаю какую-то детсадовско-гуманитарную чепуху, смысловое наполнение которой стремится к нулю. С тем же успехом ты мог бы просто написать "соси хуй" - стилистика другая, семантика та же.
Вот что бывает, когда быдло вкатывается в айти.
Я тебе дал конкретный технический ответ: маленькие изолированные куски всегда проще в поддержке и улучшайзинге, чем ёбаный монолит. Если не собираешься делать свой арканоид расширябельным, то хоть на гото пиши. Если собираешься, то надо декомпозировать задачу как можно сильнее, ослабляя зацепление и усиливая связность, в том числе: чистота отдельно, стейт отдельно, ио отдельно, конфиг отдельно итд.
А на самом деле всем похуй как ты пишешь, лишь бы арканоид получился классным. И да, соси хуй.
Ты вообще читал первый пост в этом треде? Я описываю два разных способа ослабления зацепления, и почему манаткоподобная архитектура - это на самом деле не про ослабление зацепления. В ответ ты пишешь, что надо ослаблять зацепление. Ну камон, сам понимаешь, как это выглядит.
>предлагает тыкать палочкой в стейт из каждого уголка кода
>Я описываю два разных способа ослабления зацепления
Ну ок.
>описываю, почему "тыканье стейта" полностью эквивалентно воображаемой манатной манячистоте
>Ну ок.
Ясно, значит не читал.
Схуяли эквивалентно? Например, вот у тебя есть мячик и блок, под которым мячик может пролетать и снег на заднем плане идет. Ты в какой последовательности будешь всё это отрисовывать? А надо ли вообще мячик отрисовывать? Как ты эту ситуацию будешь разруливать, когда у тебя ИО вместе со стейтом по всему коду распихано? С манатками понятно - у тебя ИО инкапсулировано и делай че хочешь: сортируй по z-индексу структурки, определяй пересечения, видимость итд.
В реальном мире (литералли во всех реальных библиотеках рендеринга) это решается через контейнеры-слои (2д) или ортографическую проекцию (2д в 3д). Какой-то неудачный пример.
Определять пересечения через ИО - это вообще какая-то пушка. Где тут связь, але? У тебя есть координаты, бери и считай, какой тут ио? За уши притягиваешь.
По-моему ты вообще не туда воюешь. Настоятельно рекомендую все-таки прочитать первый пост.
>чистота на практике?
на практике зная про эту концепцию ты будешь в промышленных языках все же минимизировать сайд-эффекты в своих функциях и методах, зная что это в общем случае полезно
на практике зная про эту концепцию ты будешь в промышленных языках все же минимизировать сайд-эффекты в своих функциях и методах, зная что это в общем случае полезно
Это и жс-макаке понятно (в 2019-то году), я про конкретный кейс описанный в оп-посте, а не про "минимизацию сайд-эффектов" вообще:
арканоид на языке программирования уже давно написан
https://ideone.com/lKzAnT
https://ideone.com/lKzAnT
перлоблядок плиз.
>на языке программирования
Ты о Clean или об Idris?
Один хуй лапша с зацеплением получится. Конкретный пример: ситуация, когда шарик сталкивается с блоком и нужно отрисовать частицы и проиграть звук. Шарик может либо сам это сделать, либо как-то дать понять, что произошло столкновение.
В первом случае шарик должен знать о существовании и иметь доступ к графической и аудио системам, что снижает связность, усиливает зацепление и усложняет конструкторы.
Во втором случае у шарика и систем должно быть какое-то соглашение, чтобы они понимать друг друга и реагировать на сообщения. Шарик может кинуть сообщение BallEvent.Impact и это опять же усилит зацепление, еще и Егор вылезет и даст пизды за енумы.
И это еще очень простой пример. А если игра имеет текстуры, а звук и частицы столкновения зависят от материала (камень или дерево, например) платформы?
Так что на хуй этих Егоров и Вестов. И программирование на хуй.
Архитектура и абстракции нужны для борьбы со сложностью
>столкновение.
Очевидно же, что в результате образовался, например, объект УничтожениеБлока, который, например, создаст объекты ЗвукУдараОБлок и РазлетающиесяЧастицыБлока. Шарик в свою очередь создаст объект ЗвукУдараОШарик.
И зацепление тут нахуй ушло, и звуки разные у разных объектов, и вообще архитектура заебись стала.
>Шарик может либо сам это сделать
Ну это уж совсем пиздец, господа.
>в результате образовался, например, объект УничтожениеБлока
new не во вторичном конструкторе?
Откуда создаваемые объекты узнают о системах звука и графики?
>еще и Егор вылезет и даст пизды за енумы.
бля проорал в голос
Ваистину язык богов. Взял и компильнул одной командой без задней мысли и можно играть. И даже не нужно устанавливать пять менеджеров зависимостей предварительно скачав менеджер менеджеров зависимостей, а после загружать несколько гигов зависимостей раздристанных по 200000 файлам по нескольким десяткам дотдриста в home директории.
>Откуда создаваемые объекты узнают о системах звука и графики?
Эти объекты уже написаны так, что используют некий HAL.
Так нельзя. Выводов может быть несколько, еще в игре есть настройки громкости звука, которые тоже нужно учитывать.
>объект УничтожениеБлока, который, например, создаст объекты ЗвукУдараОБлок и РазлетающиесяЧастицыБлока. Шарик в свою очередь создаст объект ЗвукУдараОШарик.
А потом оказывается, что когда уничтожается весь ряд блоков, то нужно играть специальный общий звук вместо индивидуальных для каждого блока (иначе все превращается в кашу), и твоя красивая архитектура идет по пизде.
Так куда выводить и с какой громкостью решает то, что находится под HAL.
>А потом оказывается, что когда уничтожается весь ряд блоков
Очевидно, тогда создается объект УничтожитьРядБлоков
>объект УничтожениеБлока, который, например, создаст объекты ЗвукУдараОБлок и РазлетающиесяЧастицыБлока. Шарик в свою очередь создаст объект ЗвукУдараОШарик.
А потом оказывается, что когда уничтожается весь ряд блоков, то нужно играть специальный общий звук вместо индивидуальных для каждого блока (иначе все превращается в кашу), и твоя красивая архитектура идет по пизде.
А с графикой как? До HAL еще далеко: надо специальный эффект с другими шейдерами отрисовать (которые еще надо загрузить).
Да и чтобы доступ к HAL получить, надо чтобы он доступен был - то есть нужен static.
Все, что ты описал можно абстрагировать, в том числе и объектами в ООП.
if(collided)
{
new SoundBlockImpact(this, collisionBlock)
.play();
new EffectBlockImpact(this, collisionBlock)
.draw();
}
Так (хоть и неправильно использовать new в методах)? Что дальше?
>хоть и неправильно использовать new в методах
А где их еще использовать, лол?
>Так
Почти. Раз у нас игра, значит объект должен тригерриться в тик игры. Значит объект имплементирует интерфйс Tickable и коннектится к источнику тиков, который вызывает интерфейсный метод tick(). А не play / draw в методе как ты сделол.
>А где их еще использовать, лол?
Пик, EO Chapter 3.6
>Значит объект имплементирует интерфйс Tickable и коннектится к источнику тиков, который вызывает интерфейсный метод tick()
new SoundBlockImpact(tickSource, this, collisionBlock)
.play();
?
Потому что объект должен знать о чем-то, перед тем как это что-то вызвать.
>EO Chapter 3.6
Егор сильно загоняется. В модели акторов, например, это нормальная ситуация.
Я имею ввиду как-то так:
constructor SoundBlockImpact(TickSource t) {
t.connect(this)
}
class TickSource {
Tickable objects;
....
method processTick() {
foreach o in this.objects: o.tick();
}
}
...
new SoundBlockImpact(tickSource);
Ты про IoC и депенденси инджекшн вообще ничего не слышал? Иди какую-нибудь книжку по хаскелю прочитай, там все объяснят. Вообще, для таких вопросов есть ньюфаг-тред, нахуй итт скатывать?
Вообще, у вас просто фестиваль говнокода какой-то. У одного игровая логика зависит от ввода-вывода и звука, у другого шарик занимается проверкой столкновений, вообще охуеть.
Ты чем читаешь? Чтобы IoC или DI объект в конструктор передать, надо чтобы вызывающий объект имел к нему доступ через аргументы метода, либо состояние.
Суть в том, что чем глубже и шире зарываешься, тем больше приходится эти объекты за собой тянуть, и они сами увеличиваются либо в размере, либо в количестве.
А Егор говорит, что 5+ аргументов в конструкторе или 3+ метода у интерфейса - говнокод.
Ну покажи нормальный код, хули ты?
Мы тут обсуждаем и критикуем различные подходы к решению интересных задач, пока ты велосипедишь очередной круд.
>А Егор говорит, что 5+ аргументов в конструкторе или 3+ метода у интерфейса - говнокод.
Кстати, что Егор говорит по поводу композиции интерфейсов? В мейнстримных ООП язычках этого нет, а очень хочется.
Что это может нарушить SRP.
Я - оп итт треда, долбоеб. Ты тут постишь говнокод.
Какие 5 аргументов? Вообще, забудь про все свои конструкторы, объекты и прочую хуйню. У тебя есть функция. Функция делает конкретную полезную работу (считает протеины, например). Она принимает на вход все, что ей нужно, и возвращает результат. "Все, что ей нужно" - это обычно мапа, в которой компоненты, конфигурации и т.п. (контекст). И дальше тут есть 2 подхода: либо каждая функция принимает контекст целиком, и там уже достает из него нужные ей вещи, либо каждая функция принимает минимальный набор компонентов, который ей нужен для выполнения задачи (первое удобнее, второе очевиднее). Если у тебя какая-то функция начинает принимать 5+ на самом деле 2+ таких аргументов, то это значит, что тебе нужно абстрагировать их в новый компонент (вместо коннектов к постгресу и к редису делай один компонент персистенс лэйер). А дальше ты указываешь реализации компонентов в конфиге и твоя DI-либа строит граф зависимостей, инициализирует (и завершает) их в нужном порядке ну и все заверте...
Объекты - это просто нескучный синтаксис для связанного набора функций с нужными им компонентами. к которому заодно прилеплены неймспейсы, статики, конструкторы, типы, фиксированная модель работы с памятью, семантика эквивалентности и прочая хуйня, накидано все в кучу и заcouplено потому что можем и "ну удобно же, ну чо"
>Ну покажи нормальный код, хули ты?
Столкновениями занимается система обработки коллизий, мячик просто имеет компонент "координаты" и все. Игровая логика (любая бизнес-логика) никогда не зависит от внешнего мира (и желательно реализована чистыми функциями, если возможно).
>Что это может нарушить SRP.
Композиция объектов и так его нарушает.
>Игровая логика (любая бизнес-логика) никогда не зависит от внешнего мира (и желательно реализована чистыми функциями, если возможно).
Сказал ОП, у которого все функции гадят в ИО и стейт.
>Вообще, забудь про все свои конструкторы, объекты и прочую хуйню.
>Объекты - это просто нескучный синтаксис для связанного набора функций с нужными им компонентами.
Ты вот это серьезно сейчас?
>мячик просто имеет компонент "координаты" и все
Мячик имеет компоненты, в том числе и физический, который и содержит "координаты", "векторы скорости и ускорения", да еще и сам решает, как и куда ему двигаться. Потому что это реальный объект, а не какая-то абстрактная система.
Так же как и твое тело и Земля сами притягиваются друг к другу, не потому, что какая-то там система говорит им как поступать, а благодаря поведению, присущим объектам с массой во Вселенной.
>Композиция объектов и так его нарушает
Каким образом?
>Сказал ОП, у которого все функции гадят в ИО и стейт.
Прочитай первый пост в треде надо было сразу в оп-пост пихать видимо, поинт вообще не в этом.
>Ты вот это серьезно сейчас?
Давай без вот этой хуйни, ок? Есть что по делу сказать - говори, приводи аргументы, а вот эти риторические вздыхания нахуй не нужны.
>да еще и сам решает, как и куда ему двигаться
Не решает, компоненты только хранят данные, поведения у них нет.
>Потому что это реальный объект, а не какая-то абстрактная система.
"Физический компонент мячика" - это реальный объект, а не какая-то абстрактная система. Ок.
>Так же как и твое тело и Земля сами притягиваются друг к другу
Не притягиваются, никакого поведения и взаимодействия у них нет, просто пространство так деформировано. Учи физику, чтобы не быть баттхертом.
>r u serius
А че нет?
>Давай без вот этой хуйни, ок? Есть что по делу сказать - говори, приводи аргументы, а вот эти риторические вздыхания нахуй не нужны.
Давай просто представим ситуацию, что у шарика может быть бустер, который несколько тиков ускоряет шарик, либо позволяет проходить сквозь блоки. Как ты это с ФП решишь (код)?
>Не решает, компоненты только хранят данные, поведения у них нет.
Ты точно туда воюешь? Я тебе про ООП говорю, где всё (в идеале) - объекты. А объекты (в идеале) не хранят данные - у них есть только состояние (неизменяемое) и поведение.
>просто пространство так деформировано
И это пространство двигает материальные объекты, да? Типа МЕНЕДЖЕР?
>у шарика может быть бустер
И в чем проблема? Цепляешь компонент CanHazBusterz, или по нажатию цепляешь сам бустер, или как там у тебя задумано.
>Как ты это с ФП решишь (код)?
При чем тут фп вообще, если речь об архитектуре как таковой?
>Ты точно туда воюешь?
Я никуда не воюю. Ты сказал, что у тебя компоненты решают, куда им двигаться. Я тебе отвечаю, что компоненты ничего не решают, компоненты просто хранят данные, по определению.
>не хранят данные - у них есть только состояние
Ну такое, да.
>И это пространство двигает материальные объекты, да?
Нет, объекты просто находятся в кривом-косом пространстве. Движение - это чисто хьюманская абстракция физика 7 класс привет. Алсо, какое это имеет отношение к разработке софта, напомни? весьма АБСТРАКТНОЕ евпочя
Ебанутые в этом итт треде пытаются сделать движок на все случаи жизни, получая в итоге жидкое нефасованное.
Все юнитятки, годоты и т.д. годятся только для лёгкой хуйни без задач на пару моделей/спрайтов с блумом и ЭшДиАр.
Все юнитятки, годоты и т.д. годятся только для лёгкой хуйни без задач на пару моделей/спрайтов с блумом и ЭшДиАр.
А ну брысь обратно в /gd, животное.
А ты пиздоглазый :3
Ну ты код-то покажи, хули?
>При чем тут фп вообще, если речь об архитектуре как таковой?
При том, что дизайны отличаются.
Какой код? На каком языке, с какой реализацией ecs, что конкретно он должен делать? Чо по срокам? Может ты все-таки сам погуглишь, что такое компоненты в ецс, ну или хотя бы сформулируешь, что тебе непонятно?
>При том, что дизайны отличаются.
Какие дизайны, чем отличаются? Единственная фп-специфичная вещь в моих постах - упоминание в скобочках того, что бизнес-логика в идеале должна быть на чистых функциях.
Ты ебанутый? Ты спизданул
>Вообще, у вас просто фестиваль говнокода какой-то
При этом ты отказываешься показать не говнокод, маняврируя.
Просто любое решение с "не говно" кодом покажи, чтобы я мог тебя лицом в него макнуть.
>Ты ебанутый?
Почему ты отвечаешь вопросом на вопрос?
>Конкретный пример: ситуация, когда шарик сталкивается с блоком и нужно отрисовать частицы и проиграть звук.
Ну, у тебя есть система, которая бегает по компонентам position+collider и кидает эвент collision(e1, e2), ты на него подписываешься и в зависимости от типов твоих энтитей проигрываешь нужный звук и спавнишь нужные частицы. Что конкретно тебе в этом решении непонятно?
>с "не говно" кодом
И про подписку поподробней.
>с "не говно" кодом
Pubsub - говнокод? Или что ты хочешь сказать? Если у тебя не хватает ума сформулировать полноценное предложение, то съеби лучше в /b или хотя бы ньюфаг-тред.
> просто пространство так деформировано
В рамках классмеха никакой деформации нет.
Ты свой код для конкретного случая привести можешь или нет, мм?
>депенденси инджекшн
Говно без задач
Капитан Относительность, мое почтение.
Ты совсем аутист? Я тебе три поста назад все подробно описал. Давай ты уже съебешь в другой тред троллить тупостью, ладно?
Ну, это зависит. Для laba1 действительно ненужно, азаза. Что именно ты понимаешь под DI?
То же что и все. Ни для чего не нужен азазазаза.
>Цепляешь компонент CanHazBusterz, или по нажатию цепляешь сам бустер
И сосешь хуй потому что скорость инкапсулирована.
>То же что и все.
Ну то есть ты не понимаешь, что это такое, и просто хотел привлечь внимание, чтобы тебе объяснили :3 ЧТД.
Попробуй написать любую систему, которая подразумевает расширение посредством плагинов (веб-фреймворк навелосипедь например, классека же), на практике сразу все встанет на свои места.
>Капитан Относительность, мое почтение.
Ну во-первых, Капитан Граница Применимости, во-вторых не деформация, а кривизна пространства-времени. А в-третьих тот анон прав и твой выпук про деформацию пространства совершенно неуместен.
НЕ НУЖНО
>веб-фреймворк
См Rails
>посредством плагинов
Нужен код который эти плагины подтягивает, DI тут вообще никаким боком. Тут еще есть момент - с перекомпиляцией или без (или на динамике); с первым попроще, а второй нахуй не нужен в 99 процентах.
>Капитан Граница Применимости
У ОТО или у классмеха? ;) Вопрос риторический.
>не деформация, а кривизна пространства-времени
>объекты просто находятся в кривом-косом пространстве
Ты какой-то аутист и сам не понимаешь, к чему приебываешься. Деформация = изменение кривизны. Иди уроки делай.
>выпук про деформацию пространства совершенно неуместен
А по-моему в этом треде неуместен ты со своими безаргументными высерами. Иди в /b с одноклассниками спорь но сперва уроки.
Куда инкапсулирована? Иди уже погугли, что такое ecs, заебал троллить тупостью.
>Нужен код который эти плагины подтягивает, DI тут вообще никаким боком
))
Почему уроки не делаете?
>Ты какой-то аутист и сам не понимаешь, к чему приебываешься.
Сказал доебывающийся до модели гравитации аутист.
>Деформация = изменение кривизны.
Иди-ка ты нахуй со своими определениями. Понятие деформации относится к ФТТ.
>А по-моему в этом треде неуместен ты
Свое мнение можешь запихать себе в жопу. Кривизна пространства-времени одна из возможных моделей гравитации.
А теперь иди учи физику и не пизди о том, чего не понимаешь.
>Сказал доебывающийся до модели гравитации
Ты обознался, я до гравитации не доебывался. Перечитай диалог.
>Кривизна пространства-времени одна из возможных моделей гравитации.
Капитан Относительность, ну мы ведь уже здоровались.
>я до гравитации не доебывался.
Ой вей, память отшибло?
>>Так же как и твое тело и Земля сами притягиваются друг к другу
>Не притягиваются, никакого поведения и взаимодействия у них нет, просто пространство так деформировано. Учи физику, чтобы не быть баттхертом.
И что не так?
Доебался до одной из моделей гравитации же.
>>Нужен код который эти плагины подтягивает, DI тут вообще никаким боком
>))
Пока что совсем жиденько. Ты уж постарайся еще, промытка дядюшки Боба и его подсосов.
Суббота же. Да и твоя мамка сама себя не выебет.
>компоненты просто хранят данные, по определению.
У тебя все определения - какое-то не общепринятое говно.
То деформация = кривиза, то ньютоновская гравитация - не гравитация, то компонент содержит только данные. Ты наркоман, чтоле?
Вообще-то я просто разместил объ указал, что существует более общая модель, в которой утверждения того анона не выполняются, да и в целом его утверждения не имеют к "Реальному Миру"(с)(тм) никакого отношения, ибо все зависит от выбранной модели (абстракции). Что не так-то?
>У тебя все определения - какое-то не общепринятое говно.
Ты за выходные так и не смог погуглить, что такое ecs. У тебя айкью где-то на уровне табуретки, покинь этот тред.
При чем тут дядюшка Боб? Передачу аргументов в функции придумал анклбоб? Ну такое.
>Вообще-то я просто разместил объ указал, что существует более общая модель
Прекращай вилять жопой, ты просто доебался до модели, что абсолютно несущественно в той беседе.
>При чем тут дядюшка Боб? Передачу аргументов в функции придумал анклбоб?
Просрал ньюфагам мозги до состояния
>хоть и неправильно использовать new в методах
скорее всего именно он.
А еще эти охуительные истории про методы не более трех строк и то что лучше вынести кусок кода чтобы дать ему имя блядь лучше чем написать комментарий. Хочется его подвесить за яйца о ставить висеть пока они сами не оторвутся.
>Ну такое.
Чмо тупое. В сраку тебя ебал.
>еще и Егор вылезет и даст пизды за енумы.
Не вылезет, потому что его здесь сразу же накормят потными нигерскими хуйцами.
В беседе о том, как многое зависит от выбранной модели, абсолютно несущественно, что существуют разные модели. Ок.
>скорее всего именно он.
Ты здесь недавно, да?
>В беседе о том, как многое зависит от выбранной модели, абсолютно несущественно, что существуют разные модели. Ок.
Выбор базовой модели основан лишь на том, какую систему моделируем. Тот анон предложил находиться в рамках классическойможет задача у него такая, но ты за каким-то хуем влез со своим релятивизмом.
>Ты здесь недавно, да?
Я тут самый алтфак, дебич. По делу есть что спиздануть?
Какие нахуй DI IOC Монады хуяды сайдеффекты. Вы что ебанутые?
Память - плоская. Там вперемешку данные и инструкции для ЦП.
ЦП делает то, что написано в памяти, пока не остановится.
Все нахуй.
Память - плоская. Там вперемешку данные и инструкции для ЦП.
ЦП делает то, что написано в памяти, пока не остановится.
Все нахуй.
>Но на практике я тупо вместо сайд-эффектного update или render возвращаю структуру, которая это описывает. И она тут же выполняется. Все, больше с ней ничего не происходит.
Не-а.
Если при создании игры ты в любой момент можешь поставить твои эвенты на паузу, откатить, смотреть покадрово и т. п., это очень сильно облегчит тебе тюнинг игровой механики, записывание демок, а если говорить не про игры, то undo-redo и прочее прочее. По умолчанию это лучшая архитектура. На практике.
>inb4 все что ни си сасает по производительности
Твое творение? Признавайся.
Ну где же вы, мамкины архитекторы?
Ты оп?
>Я тут самый алтфак
))
>Тот анон предложил находиться в рамках классической
Нет, он такого не предлагал. Он начал заливать про то, что ВОТ В РЕАЛЬНОМ-ТО МИРЕ у нас объекты друг в друга гравитацией кидаются и время существует, на что я ему провел по губам своим релятивизмом.
Я ждал этого коммента. Спасибо!
Первый коммент по теме треда, мое почтение.
Нюанс в том, что на практике все эти undo-redo и прочие откаты нужны в одном случае из ста. (Вообще, я об этом писал в начале треда.) А в 99 случаях из ста они висят мертвым весом, пока ты думаешь, что ну вот в следующий раз оно обязательно пригодится. Вообще, это (оверинжиниринг) - одна из форм преждевременной оптимизации. Вместо того, чтобы решать поставленную задачу, ты выдумываешь сам себе новые задачи, которые к изначальной, как правило, имеют мало отношения.
Так вот, а в том 1 случае из ста, когда тебе это действительно нужно, на практике ты можешь добиться того же эффекта просто грамотно подходя к хранению данных. Если стейт у тебя лежит в едином хранилище (а это справедливо и для современного клиент-сайда, и для игрушек на ецс, и даже внезапно для типичной веб-хуйни), то тебе не составит труда навесить вотчеров на это хранилище и точно так же записывать свои эвенты - при том только те, что тебе нужны, и только тогда, когда тебе это нужно. Без оверхеда в остальных случаях.
Test
>Нюанс в том, что на практике все эти undo-redo и прочие откаты нужны в одном случае из ста.
Undo-redo нужны в любом пользовательском софте.
В одном случае из ста при выбранных архитектурных решениях добавление undo-redo системы в текущий код выгодно. В 99 - не выгодно. Но это не значит, что не нужно.
Иными словами, кодер пишет как придется, через год его программа выстреливает и юзеры молят об undo-redo, а менять что-либо в этой императивной лапше уже тяжело, вот и отписывается он, не нужно мол, я не буду два месяца перепиливать код.
А если писать сразу как надо, то тебе и undo-redo реализовать просто, и сам код не становится сложнее, чем был. Что касается оверхеда, то вряд ли он будет на самом деле. Если у тебя игра, то список не обязательно хранить - выполнил и выкинул. А самые тяжелые части у игр это точно не подобная логика.
>одна из форм преждевременной оптимизации
Наоборот. Это у тебя преждевременная оптимизация - ты заранее решил, что такая архитектура якобы затратна по сравнению с грязным стейтом. Это в худшем случае преждевременная пессимизация.
Тут дело в другом - так писать непривычно. Но не сложнее.
>Undo-redo нужны в любом пользовательском софте.
Ну вот джвач как бы тоже "пользовательский софт". Куда тут андо-редо? Анон, не нужно таких сомнительных овергенерализаций.
>В 99 - не выгодно. Но это не значит, что не нужно.
Ну хуй знает, какие-то у тебя странные представления о мире. I'm a simple man, u menya rynochek reshaet В твоем примере это же как раз выгодно (не пришлось бы переделывать архитектуру, чтобы решить поставленную задачу), просто кодер с перспективой не угадал.
>А самые тяжелые части у игр это точно не подобная логика.
Ну ты выше говорил о реплеях и подобной шняге. Для этого тебе все изменения состояния в игровой логике нужно прогонять через "создал - выкинул".
>Это у тебя преждевременная оптимизация - ты заранее решил, что такая архитектура якобы затратна
Я ведь говорю не только (и не столько) о затратах памяти и цпу. Я говорю об усложнении архитектуры, об усложнении кода, об увеличении когнитивных затрат. Без видимых преимуществ.
>Тут дело в другом - так писать непривычно. Но не сложнее.
Ну кому как, мне-то как раз привычно. Ты вообще почему-то выше говорил об "императивной лапше", хотя я в общем-то рассматриваю два подхода, которые применимы в функциональном коде.
Алсо, ты никак не адресовал мой последний абзац, который решает все описанные тобой в этом посте проблемы с использованием другого подхода и без оверхеда.
>через год его программа выстреливает и юзеры молят об undo-redo, а менять что-либо в этой императивной лапше уже тяжело
Если ты делаешь какой-то редактор, то undo-redo подразумевается изначально, и соответственно закладывается при проектировании. В функциональщине у тебя отмены вот прямо искаропки не будет, все равно придется какую-то полноценную систему проектировать. Задавать сущности для стека команд, слияния команд, и т.д.
>при создании игры ты в любой момент можешь поставить твои эвенты на паузу, откатить, смотреть покадрово
Это легко делается на крестах без всякой функциональщины. Выделяется арена под стейт игры, и туда пишутся стейты кадров, как в кольцевой буфер. Так, кстати, менеджмент ресурсов получается проще, чем с персистентным мутабельным стейтом.
Ну если ты юзаешь например что-то типа https://github.com/tonsky/datascript для хранения стейта, то именно что будет и именно что искаропки. Но для этого тащем-то манаток и ивент сорсинга как раз и не надо. Да и в принципе в любом языке с персистентными структурами простейший андо-редо делается нахаляву в полторы строчки. Это если тебе надо как в имаксе например строить дерево всех путей редактирования, по-умному объединять отдельные изменения в целостные команды - это да, тут придется немного повозиться. Но все равно на порядок проще, согласись.
>Так, кстати, менеджмент ресурсов получается проще, чем с персистентным мутабельным стейтом.
Раскрой мысль, если не затруднит?
-кун
>Раскрой мысль, если не затруднит?
С мутабельным стейтом надо велосипедить фактически маленький перемещающий сборщик мусора, менеджить удаление/добавление компонентов, поддерживать консистентность ссылок (например, если компоненты лежат в линейном массиве и при удалении последний элемент перемещается на место удаленного).
С (почти) иммутабельным стейтом все делается в одну фазу при копировании компонентов в новый фрейм. Внутри фрейма компоненты только добавляются, мертвые компоненты просто помечаются на удаление. В фазу копирования в новый фрейм копируются только живые компоненты, одновременно обновляются ссылки.
То есть сразу исчезают проблемы с компактностью, поскольку все компоненты лежат линейно после копирования в новый фрейм, и с валидностью ссылок, поскольку перемещение компонентов происходит только между кадрами.
А, меня просто смутило выражение "персистентный мутабельный"
>смутило выражение "персистентный мутабельный"
Ну я не знаю как еще описать такую структуру, которая мутабельная, но при этом сохраняет состояния.
> С (почти) иммутабельным стейтом все делается в одну фазу при копировании компонентов в новый фрейм. Внутри фрейма компоненты только добавляются, мертвые компоненты просто помечаются на удаление. В фазу копирования в новый фрейм копируются только живые компоненты, одновременно обновляются ссылки.
Я понимаю, что с т.з. прямоты кода персональный GC это персональный ад, но все же после
> все компоненты лежат линейно после копирования в новый фрейм
я думаю, что это прям deep копирование и жестокий memory pressure, это же не может работать быстро, не?
а если там иммутабельность и ссылки, то какая к черту компактность?
Привет дорогой React.js разработчик.
>я думаю, что это прям deep копирование и жестокий memory pressure, это же не может работать быстро, не?
Copy on modify.
хотел сказать copy on write? но анон же действительно хочет писать/компактить, а значит cow не имеет значения для вопроса
Если под компактностью понимается: прям вот друг за дружкой в памяти, то это делается только для одного: избежать промахов кэша цп и хорошо работает только в случае DOD, что вообще не вяжется с какой ни было вменяемой предметно-ориентированной архитектурой.
>что вообще не вяжется с каким ни было вменяемым геймдевом кроме соснульных эксклюзивов, где подобная анальная акробатика вынуждена в ввиду немощности соснулей.
Поправил тебя. Если заглянуть в ванильные сорцы хоть уеча, хоть круйзиспихла, то никакого DOD ты там не найдешь.
Алсо, дивитесь якой говнокод отвечал за топ графин несколько лет назад:
https://github.com/CRYTEK/CRYENGINE/tree/release/Code
Пиздец. Если опустить байтолюбство, то тут вот прямо говнокомбо как в тырпрайзном проекте на жабе с прошлой работы. И это вот каждый батяодобряе еба-шутан так написан?
>Ну вот джвач как бы тоже "пользовательский софт". Куда тут андо-редо? Анон, не нужно таких сомнительных овергенерализаций.
Двач - бесплатный серверный софт с сомнительной окупаемостью. Ундо-редо есть на уровне браузера, это спасает. Впрочем, я бы не отказался бы и от отката постов и тому подобного. Да что там, двач даже пост при закрытии вкладки не сохраняет, хотя trello это много лет как умеет. Но trello это бизнес, а двач хуйня из по коня.
>Ну ты выше говорил о реплеях и подобной шняге. Для этого тебе все изменения состояния в игровой логике нужно прогонять через "создал - выкинул".
Это не обязательно должно быть дорого. Изменения можно хранить в кольцевом буфере произвольной длины, вплоть до длины 2. То есть следующий кадр - функция от пользовательского инпута и предыдущего кадра. В итоге ты пишешь
x[t] = x[t-1] + 1 вместо x = x + 1. Это не стоит практически нихуя. Нужны логи - увеличиваешь размер буфера.
>Это легко делается на крестах без всякой функциональщины.
Да я против функциональных языков как явления. У опа был вопрос про "логика отдает некие структуры, описывающие действия, а внешний грязный интерпретатор их потом выполняет".
Вот это охуенно, а функциональщину, которая даже мутабельные локальные переменные не признает, в пизду.
>мутабельные локальные переменные
А нахуя они нужны? В результате TCO при компиляции всё немутабельное, до чего сможет доебаться оптимизатор, становится мутабельным.
>А нахуя они нужны
Хранить промежуточный стейт
>В результате TCO при компиляции всё немутабельное, до чего сможет доебаться оптимизатор, становится мутабельным.
Вот то, что ты описал, точно нахуй не нужно. Если мне нужен цикл, я напишу цикл, а не буду делать хвосторекурсивную функцию, которая этот цикл эмулирует забив на какую-либо структурность программирования, и дальше надеяться на то, что оптимизатор что-то там соптимизирует. В этом ноль смысла.
>хвосторекурсивную функцию
Не обязательно только хвосто рекурсивную, TCO подразумевает несколько более широкий спектр задач.
>забив на какую-либо структурность программирования
Рекурсия чаще выглядит понятной, нежели цикл.
>В итоге ты пишешь x[t] = x[t-1] + 1 вместо x = x + 1
>=
Бля, анон, перечитай цепочку диалога внимательнее, пожалуйста, ты вообще мимо на тот гринтекст ответил.
>Вот это охуенно
Так это и есть чистый функциональный дизайн а-ля хаскель, привет.
>функциональщину, которая даже мутабельные локальные переменные не признает
Вообще-то признает, с добрым утром но они ненужны, кроме редких случаев оптимизации или написания какого-то хитровыебанного алгоритма, который проще с локальной мутабельностью с псевдокода в пейпере списать
>Если мне нужен цикл, я напишу цикл
Так тебе не нужен цикл.
Объясните нафане в архитектуре как сделать пиздато.
Читаю всякие ништяки как люди делают движки на функциональщине, DataOrientedDesign и с ECS, сам пилил максимум демо-портянки, которые нормальным людям показывать нельзя.
Реально ли мочь в дизайн и код одновременно или в одно ебало это нереально?
Читаю всякие ништяки как люди делают движки на функциональщине, DataOrientedDesign и с ECS, сам пилил максимум демо-портянки, которые нормальным людям показывать нельзя.
Реально ли мочь в дизайн и код одновременно или в одно ебало это нереально?
Ну вот выше анончик кинул гитхаб с исходниками круйзиса.
Не, самая ПУШКА это вот:
- ШЕФ, У НАС ПРОБЛЕМА, НАМ НУЖНО ПОРТИРОВАТЬ ДВИГ С ШИНДОШС НА ДРУГИЕ ПЛАТФОРМЫ, А У НАС РЕНДЕР ГВОЗДЯМИ ЗАХАРДКОЖЕН ПОД DirectX , НАМ ПИЗДЕЦ ШО ДЕЛАТЬ?
-СПАКУХА, ПОТСОНЫ:
https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/DXGL/CryDXGL.cpp
https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/Vulkan/D3DVKConversionUtility.hpp
https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/Vulkan/CryVulkanWrappers/Resources/CCryVKShaderReflection.cpp
https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/ropeentity.cpp
Мощно
https://www.pcgamer.com/crysis-3-performance-issues-caused-by-ropey-physics/
Как бы неудевительно, что это писали СНГ-шные слесари
Мощно
https://www.pcgamer.com/crysis-3-performance-issues-caused-by-ropey-physics/
Как бы неудевительно, что это писали СНГ-шные слесари
Надо сказать код крайтек довольно аккуратный, за исключением мест, написанных блохастыми. В индустрии все было хуже и намного.
https://github.com/JACoders/OpenJK/blob/master/code/game/wp_saber.cpp
>Надо сказать код крайтек довольно аккуратный
>https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/
Ну старые апи до вулкана и дх12 по причине их глобально-стейтовой природой действительно сложно абстрагировать красиво без прибивания гвоздями к коду.
Нахуй мне ваша чистота на практике? Хаскели-хуяскели.
Вот пишу я арканоид. Ну ок, логика чистая, все как по книжке, четко-красиво.
Манатки-хуятки, ну хуй с ними, вот просто моя логика отдает некие структуры, описывающие действия, а внешний грязный интерпретатор их потом выполняет.
Но на практике я тупо вместо сайд-эффектного update или render возвращаю структуру, которая это описывает. И она тут же выполняется. Все, больше с ней ничего не происходит.
В теории - ок, тестирование там, прозрачность, интроспекция, хуе-мое.
Но у меня не эвент сорсинг, я арканоид пишу. А писал бы эвент сорсинг - вся эта хуйня все равно делалась бы через базу.
Ну и нахуй мне ваша чистота на практике?