Wolsh, не ну это круто конечно! Я за уже почти 15 лет плотного занятия 3D-графикой никогда даже не пытался в таком ключе интерпретировать систему записи цветов RGB. Вон он - образ мыслей программиста.
Уточни, пожалуйста, другое. В какой-то теме ты уже приводил как раз такую запись значения и все уже обсуждали цвета. Но оно было введена "от руки", т.е. напрямую что-то типа 0x604181. И это не было результатом работы какого-то кода. Значит ли это, что подобный подход - использовать вложенные массивы-справочники - реализуется не непосредственно в создаваемой программе, а где-то "на стороне"?
И ещё за общими рассуждениями замылился мой второй вопрос. Что думаете на счёт использования справочников синхронизации между Моделью и Вью?
Добавлено через 13 часов 3 минуты
Друзья, я с позволения конкретизирую вопрос. Давайте посмотрим под углом любимой всеми нами MVC на конкретном примере
Вот смотрите. У меня есть такая штука как варианты действия. Например, если игрок выбрал "ударить", то следом игра его спрашивает, как: "слабо", "сильно", "со всей дури". Это экземпляры отдельного класса. Содержат модификаторы к значениям действия (если "сильно", то точность падает, а усталость возрастает и т.п.). Чтобы выводить их в диалог, предусмотрены строковые ID, которые передаются во Вью в метод формирования меню. Он лезет в класс LanguagePack и вытаскивает по ID конкретные фразы на нужном языке.
Чтобы не утонуть в многочисленных фразах, языковой файл иерархически разбит на секции. ID секции принимается первым обязательным параметром метода подбора фразы. Таким образом, для подбора конкретного лэйбла кнопки с вариацией запрос выглядит следующим образом:
Код AS3:
var label: String = LanguagePack.getSinglePhrase(LanguageIDs.SECTION_AV_BUTTONS, variation.variationID);
Теперь я добавил игровые предметы. И потребовалось сделать принципиально новые вариации действий. Например для действия "лечиться" предстоит выбрать, чем: боярышником или коньяком. В Модели всё получилось прекрасно: унаследовался от VariationEntity и переписал геттер, чтобы вместо фиксированного перечня он подбирал вариации по предметам нужного типа из наличия. В общем, всё "срослось". А вот во Вью затык! Ведь лэйбл для фразы теперь нужно подбирать не из секции наименований вариаций (SECTION_AV_BUTTONS), а из секции названий предметов (SECTION_ITEM_NAMES). Вью "не знает" и "не может знать" этого.
Альтернативы мне видятся такие:
1. Инкапсулировать подбор лэйбла прямо в классе вариации. Ведь каждый наследник точно "знает", с чем он работает, и может сам обратиться к языковому файлу, чтобы приготовить и записать для себя лэйбл. А метод подготовки меню - просто его вытаскивать и лепить на кнопочку, не приходя в сознание. Но мне этот подход почему-то кажется каким-то "неMVC-шным". Я старался, чтобы на уровне Модели (а создание и подбор вариаций действия - прерогатива Модели, без сомнения) вообще не фигурировали никакие конечные выводимые объекты, будь то тексты или картинки.
2. Добавлять логику в класс подбора фраз. Собственно то, о чём я раньше спрашивал в этой теме. Чтобы некий отдельный метод (или целый Класс) получал ID фразы из Модели (вот тут как раз будет неважно, String или 16х uint или что-то ещё) и по нему выдавал нужную фразу. Здесь главная проблема - это контекст. Как видно из примера (я для этого его так подробно и описывал), может быть много контекстов. Их формализация и передача в метод-посредник - отдельный геморрой с непонятными перспективами.
Застрял я конкретно. Пока не решу, боюсь дальше двигаться, ибо по мере добавления функционала проблема усугубляется. Просьба прокомментировать мои варианты. Спасибо.