Информация об изменениях

Сообщение Re[20]: Cоздание базового шаблона минуя специализацию от 29.10.2022 10:03

Изменено 29.10.2022 10:56 rg45

Re[20]: Cоздание базового шаблона минуя специализацию
Здравствуйте, so5team, Вы писали:

S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?


S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.


S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.


Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:

  • можно определять пользовательские форматтеры в одном пространстве имен с пользовательскими типами,
  • можно предоставлять форматтеры по умолчанию для целых пространств имен
  • можно повторно использовать предопределенные наборы форматтеров для новых типов при помощи using-declarations

В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно выше, чем в текущем подходе со специализациями.

Re[20]: Cоздание базового шаблона минуя специализацию
Здравствуйте, so5team, Вы писали:

S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?


S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.


S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.


Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:

  • можно определять пользовательские форматтеры в одном пространстве имен с пользовательскими типами,
  • можно предоставлять форматтеры по умолчанию для целых пространств имен
  • можно повторно использовать предопределенные наборы форматтеров для новых типов при помощи using-declarations
  • еще одна важная деталь: фабрика форматтера получает параметром объект и у теперь и форматтер теперь может быть чувствителен к свойствам объекта, для которого он создается.

В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно выше, чем в текущем подходе со специализациями.