Согласен, с namespace-ами получится +- то же самое. Тут уже дело вкуса, как мне кажется. Статья в целом про подход, я материалов и примеров про такое их использование не нашёл.
Юнион не схлопнется, но и смысла в нём не прибавится, т.к. все равно string уже включает в себя значения 'foo' и 'bar'.
1) Так "жирнее" импорты, может быть ощутимо в файле где используется много типов.
2) Если у вас будет много типов, то получится та самая проблема, которую я предлагаю решить. Либо у вас везде type guard-ы называются is и тогда intellisense вам не поможет, либо каждый type guard в имени будет содержать имя типа, тогда опять же вспоминать названия и ещё "жирнее" импорты.
Это все может не быть проблемами в небольших проектах, но с увеличением кодовой базы начнет сказываться.
В рамках примера да, проще использовать enum. Но пример очень упрощён.
Если рассматривать вопрос шире, то enum не поможет, если потребуется, например дженерик или объектный тип.
В случае с объектным типом, для сбора утилит в одном месте подошёл бы и класс со статичными методами. Но он же не подошёл бы для примера с union type в статье.
Мне тем и нравится подход с воплощёнными типами, что он позволяет эффективно и единообразно решить проблему для всех возможных видов типов.
Согласен, с namespace-ами получится +- то же самое. Тут уже дело вкуса, как мне кажется. Статья в целом про подход, я материалов и примеров про такое их использование не нашёл.
Юнион не схлопнется, но и смысла в нём не прибавится, т.к. все равно string уже включает в себя значения 'foo' и 'bar'.
Можно, но это:
1) не решает проблему с разрозненными утилитами;
2) намного ближе к теме номинальных типов, её я не планировал затрагивать в данной статье.
Кстати, номинальный тип можно определить как воплощённый (в соответствии с терминологией из статьи) и так с ним будет работать намного удобнее :)
1) Так "жирнее" импорты, может быть ощутимо в файле где используется много типов.
2) Если у вас будет много типов, то получится та самая проблема, которую я предлагаю решить. Либо у вас везде type guard-ы называются is и тогда intellisense вам не поможет, либо каждый type guard в имени будет содержать имя типа, тогда опять же вспоминать названия и ещё "жирнее" импорты.
Это все может не быть проблемами в небольших проектах, но с увеличением кодовой базы начнет сказываться.
В рамках примера да, проще использовать enum. Но пример очень упрощён.
Если рассматривать вопрос шире, то enum не поможет, если потребуется, например дженерик или объектный тип.
В случае с объектным типом, для сбора утилит в одном месте подошёл бы и класс со статичными методами. Но он же не подошёл бы для примера с union type в статье.
Мне тем и нравится подход с воплощёнными типами, что он позволяет эффективно и единообразно решить проблему для всех возможных видов типов.