Здравствуйте, so5team, Вы писали:
S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?
S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.
S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.
Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:
можно определять пользовательские форматтеры в одном пространстве имен с пользовательскими типами,
можно предоставлять форматтеры по умолчанию для целых пространств имен
можно повторно использовать предопределенные наборы форматтеров для новых типов при помощи using-declarations
еще одна важная деталь: фабрика форматтера получает параметром объект и теперь форматтер может быть чувствителен к свойствам объекта, для которого он создается, а не просто конструироваться по дефолту, как раньше. Например, форматтер может использовать полиморфно идиому pImpl и создавать различные внутренние имплементации форматирования в зависимости от каких-то runtime свойств объекта.
В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно лучше, чем в текущем подходе со специализациями.
