с пунктом 3 я полностью согласен, что так делать по-идее нельзя, но реальная практика диктует свои правила и уже в css фреймворках появляются utils классы, которые проще вставить, чем для каждого блока/элемента добавлять необходимые паддинги, марджины и тд
Тот факт, что модификаторы вырождены до одного css-свойства, не превращает БЭМ в AtomicCSS.
Можно конечно подогнать под БЭМ всё что угодно, но как минимум сам нейминг нарушает основной принцип лучших CSS практик, а именно привязка к CSS свойствам (за что ругают Атомик, Бутстрап и им подобные). Емнип БЭМ - это фактически топовая методология CSS с лучшими практиками и не может априори их нарушать.
Евгений Ромашкан, ну это вы, это первое. Большинство же в 17 лет слабо представляют, кем будут, в виду особенностей личности и воспитания. Второе, если колледжи не нужны, почему туда толпы народа, а на IT специальности даже за деньги не в каждый колледж можно попасть? Были бы бесполезны - позакрывались бы все уже давно.
Ну задача не в этом же. Нужно просто, чтобы каждый пользователь создал себе колобка с уникальными характеристиками и затем наблюдал за ним (звучит глупо, но это обучающая задача)
Rsa97, под парсингом я имел именно обработку полученных данных. То есть покрыть всё условными операторами? Или существует определённая методика для таких объектов (которые содержат не только данные, но и логику для вызова тех или иных методов)
Правильно ли я понимаю, что парсить такое - это отдельный навык? Какие существуют паттерны проектирования под такие структуры данных? Можно, конечно, банально обвесить всё условными операторами, но что-то мне подсказывает, что в итоге будет лапшекод.
Максим, И да, анализ на совпадение множеств будет реализован через циклы, т.е. с практической точки зрения мы не имеем дело с одновременностью, согласен.
sim3x, это конечно хорошо. В данном случае будет анализ поля зрения на попадание именного этого множества животных в поле зрения и реализация закреплённого для данного множества действия. Другими словами, совпадение описанного множества и множества реальных животных, которые в поле зрения в процессе игры - это симуляция одновременности (а по сути и есть она). Про Тьюринга конечно не в курсе.
sim3x, кажется понял, к описанной выше структуре нужно добавить ещё одно поле в роде "действие в случае столкновения с несколькими" и назначить для каждого множества персонажей своё отдельное действие.
И так добавлять и другие поля, по мере возникновения хотелок. В итоге получится своего рода "язык" для создания уникальности колобков. По-сути, вместо изобретения языка программирования, что является преждевременной абстракцией, мы осуществим решение задачи за счёт банального итеративного процесса разработки.
с пунктом 3 я полностью согласен, что так делать по-идее нельзя, но реальная практика диктует свои правила и уже в css фреймворках появляются utils классы, которые проще вставить, чем для каждого блока/элемента добавлять необходимые паддинги, марджины и тд