Единственное, что у меня можно было бы назвать эксперементальным - это аспекты. Многие другие языки выглядят гораздо более экспериментальными. Управление памятью - ручное. Конструкторов и деструкторов - нет. Возможно стоило бы добавить операторы для явного копирования и перемещения, но, мне кажется, в Си и без них хорошо. В любом случае, я не планирую реализовывать эти идеи.
И сколько времени потребуется, чтобы набросать подобные абстракции? Теперь, каждый опытный и не опытный разработчик может использовать мой фремворк. Разве это плохо? Многие проекты, кстати, вообще не имеют четкой архитектуры. Для решения этой проблемы и были придуманы фреймворки типа ribs. Что именно выглядит не очень? У вас есть идеи получше? Предлагайте!
Есть прикол, что компилятор может неявно создавать копии readonly структур, чтобы гарантировать их имутабельность. И особенно прикольно, если это происходит в цикле...
И все IT в такой же ж***( Много новых языков и каждый со своими тараканами.
Там еще контрольная группа была, которая жила в таких же условиях, но думала о чем-то другом. Вчера забыл про это.
В любом случае без подробной информации об улучшениях, сложно делать выводы. Возможно они чувствовали себе более счастливыми, вырабатывалось больше эндорфинов или чего-то подобного, что приводило к незначительному улучшению состояния.
Из вики (Эндорфины):
О том, что раны победителей заживают быстрее, чем раны побеждённых, было известно ещё в Древнем Риме.
А на сколько улучшилось зрение?
Мне кажется состояние людей могло улучшиться по другим причинам. Например: черно белый телевизор меньше влияет на зрение или лучше отдыхали, что могло улучшить память.
А как обстоят дела с модульностью в анриале?
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
При использование Composition Root, все связи видны как на ладоне. Как минимум это должно упростить жизнь новым программистам на проекте.
Я сейчас читаю книгу «Dependency Injection in .NET». Там об этом написано. Хотя там написано про инициализацию зависимостей, но думаю к сигналам и командам это тоже относится.
Я в игре могу подвесится прям на команды как на события. И тоже строготипизированно. Выглядит как-то так:
В StrangeIoC есть два вида событий: старые событий и новые сигналы. Я это имел ввиду.
Чем упрощают? Что для вас «асинхронные» в данном контексте?)
Команда выполняется в течении нескольких кадров. Проще вызвать другую команду в конце асинхронной команды. Иначе нужен будет или callback или promise.
Чтобы просто не создавать классы размером в 1000 строк, можно использовать шаблон стратегия. Хотя я часто пишу статические классы — утилиты или хелперы.
Суть команд, мне кажется, больше, чем просто декомпозиция большого класса.
commandBinder.Bind(GameEvent.HIT).To<DestroyEnemyCommand>().To<UpdateScoreCommand>();
commandBinder.Bind(GameEvent.HIT).InSequence()
.To<CheckLevelClearedCommand>()
.To<EndLevelCommand>()
.To<GameOverCommand>();
injectionBinder.Bind<ICommandBinder>().To<SignalCommandBinder>().ToSingleton(); // сигналы - новые, строго типизированные события.
https://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Это должно проделываться в Composition Root. Вызов одной команды из другой это явно плохая практика.
Кстати, в StrangeIOC команды могут быть асинхронными, в этом случае они конечно упрощают жизнь. Хотя я для этого использовал Promise, которые очень популярные в JS.
файле на тысячи строк
Я не говорил, что надо вообще все в один файл писать. Но создавать файл для каждой функции, еще и в 1-5 строк… это странно для меня. Хотя конечно можно в одном файле написать несколько классов.
Но остается проблема с GC. У вас некоторые команды создавались в каждом update, рано или поздно это может внести свою лепту в понижение fps.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.
Единственное, что у меня можно было бы назвать эксперементальным - это аспекты. Многие другие языки выглядят гораздо более экспериментальными. Управление памятью - ручное. Конструкторов и деструкторов - нет. Возможно стоило бы добавить операторы для явного копирования и перемещения, но, мне кажется, в Си и без них хорошо. В любом случае, я не планирую реализовывать эти идеи.
Для начала было бы хорошо написать семантическую модель для языка. Но я слабо представляю как реализовать некоторые вещи.
Я добавил объектный стиль и аспекты. Получилось что-то среднее между Си и С++. На мой взгляд это золотая середина для многих задач.
Я просто размышлял каким могбы быть Си, если бы можно было вернуться в прошлое и исправить все его ошибки.
Все правильно.
И в чем тут проблема?
Возможно мелкие недочеты остались, но в целом все правильно.
Какие пёрлы? И чем вам не нравится Java стиль?
И сколько времени потребуется, чтобы набросать подобные абстракции? Теперь, каждый опытный и не опытный разработчик может использовать мой фремворк. Разве это плохо? Многие проекты, кстати, вообще не имеют четкой архитектуры. Для решения этой проблемы и были придуманы фреймворки типа ribs. Что именно выглядит не очень? У вас есть идеи получше? Предлагайте!
А кто-то делал подобное? MonoGame это совершенно другое.
И как же правильно надо реализовывать IDisposable?
Наверное я что-то перепутал. Но все равно поведение компилятора очень странное.
Есть прикол, что компилятор может неявно создавать копии readonly структур, чтобы гарантировать их имутабельность. И особенно прикольно, если это происходит в цикле...
И все IT в такой же ж***( Много новых языков и каждый со своими тараканами.
Нужно было изначально делать D и D++.
В любом случае без подробной информации об улучшениях, сложно делать выводы. Возможно они чувствовали себе более счастливыми, вырабатывалось больше эндорфинов или чего-то подобного, что приводило к незначительному улучшению состояния.
Из вики (Эндорфины):
Мне кажется состояние людей могло улучшиться по другим причинам. Например: черно белый телевизор меньше влияет на зрение или лучше отдыхали, что могло улучшить память.
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
При использование Composition Root, все связи видны как на ладоне. Как минимум это должно упростить жизнь новым программистам на проекте.
Я сейчас читаю книгу «Dependency Injection in .NET». Там об этом написано. Хотя там написано про инициализацию зависимостей, но думаю к сигналам и командам это тоже относится.
В StrangeIoC есть два вида событий: старые событий и новые сигналы. Я это имел ввиду.
Команда выполняется в течении нескольких кадров. Проще вызвать другую команду в конце асинхронной команды. Иначе нужен будет или callback или promise.
Чтобы просто не создавать классы размером в 1000 строк, можно использовать шаблон стратегия. Хотя я часто пишу статические классы — утилиты или хелперы.
Суть команд, мне кажется, больше, чем просто декомпозиция большого класса.
https://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Это должно проделываться в Composition Root. Вызов одной команды из другой это явно плохая практика.
Кстати, в StrangeIOC команды могут быть асинхронными, в этом случае они конечно упрощают жизнь. Хотя я для этого использовал Promise, которые очень популярные в JS.
Я не говорил, что надо вообще все в один файл писать. Но создавать файл для каждой функции, еще и в 1-5 строк… это странно для меня. Хотя конечно можно в одном файле написать несколько классов.
Но остается проблема с GC. У вас некоторые команды создавались в каждом update, рано или поздно это может внести свою лепту в понижение fps.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.