AR
И лучше в этом случае не enum, а fname
Size: a a a
2020 May 20
n
И лучше в этом случае не enum, а fname
а чего не енам?
AR
ну удобнее мапу, с ключами по енам, а значения FText'ы
String table лучший вариант
n
String table лучший вариант
ну по-сути это тоже мапа же? не смотрел как оно внутри)
AR
а чего не енам?
В блупринтах в принципе пофиг, но они для другого предназначены. Для ключей лучше fname
AR
ну по-сути это тоже мапа же? не смотрел как оно внутри)
По сути локализация под них заточена
n
В блупринтах в принципе пофиг, но они для другого предназначены. Для ключей лучше fname
если ключи таблицы - то конечно, да. Но в TMap удобнее сразу енам, чтоб не конвертировать
n
а то получится сначала енам в fname, потом по fname получать текст...
AR
Есть хорошая практика все тексты хранить в string table. К ftext оно подключается встроенными средствами, а для енума выбор текста из мапы - оверкилл
AR
Енам вообще нужен для логики. Для бранчей, свитчей и т.д. Вообще енам - это хардкод. Ключи же - динамика
Оу
так как сделать лучше?
AR
Если мне нужно в зависимости от ключа сделать разные действия - я выберу enum, т.к. у меня ограничен набор вариантов. Если у мне нужно протегировать данные, которые можно неограниченно расширять - я выберу fname
Оу
fname - это блюпринт класс?
AR
Он всё ещё учит php
так как сделать лучше?
Выбор из string table и вместо enum fane, если нет разных веток логики в зависимости от значения
AR
Это тип переменной
Y
просто Name в Бп
n
Если мне нужно в зависимости от ключа сделать разные действия - я выберу enum, т.к. у меня ограничен набор вариантов. Если у мне нужно протегировать данные, которые можно неограниченно расширять - я выберу fname
так может там логика по енаму и в зависимости от стейта надо разный текст показывать)
Оу
это при создании человечка присваивать ему имя, фамилию, дату рождения и т.д. случаным образом