Здравствуйте, KeyKeeper, Вы писали:

KK>Исходную задачу Вы поняли абсолютно верно.

У нас тут принято на "ты", если это не смущает, то предлагаю перейти на ты.

KK>Нужна универсальная фабрика. Вторая задача, возникшая по дороге — понять, какие подходы можно использовать, если решать на Nemerle.

Для этого нужно понять более общие задачи. Самой частой ошибкой, при разработке софта на Немерле, является попытка проектирвоать в стиле того языка который был знаком до этого (например, шарпа). Это, конечно, тоже можно, но не так эффективно по сравнению с проектированием с учетом всех возможностей языка.

В прочем, для начального знакомства пограммирование в стиле C#++ тоже полезно. Но лучше потренироваться на кошках (мелком проекте). А при разработке чего-то более сложного подумать над дизайном по сильнее (с учетом опыта).

Лично я уже забыл когда занимался созданием проксей или использованием разных DI-технологий. Все эти подходы, обычно, решают одну и ту же задачу — упрощение написания скучного кода. Но на немерле этот скучный код можно просто не писать! Его можно сгенерировать по модели.

По сему имеет смысл взять исходную задачу и рассмотреть ее в самом абстрактном виде. Потом нужно прикинуть нельзя ли ее описать в виде какой-то высокоуровневой модели которую можно выразить в виде условного языка. Если это удастся, то весь скучный код можно будет просто сгенерировать по такой модели. Конечно, придется потратить время на написание генератора, но это как раз уже не скучно.

Данный подход оправдан когда объем скучного кода большой. Причем чем больше может быть кода, тем более оправдан подход.

Другой вариант изменение дизайна с ООП на ФП. Этот вариант оправдан когда речь идет о пакетной обработке данных. Когда есть входные данные и их нужно преобразовать в другой вид.

KK>Это тоже отличная новость, потому что не знал, как избежать дорогого Activator.CreateInstance() в C#.

В C# можно делать точно так же. Единственная проблема заключается в том, что шарп не превращает конструкторы в функции и не умеет выводить параметры типов для конструкторов, так что кода будет больше. Но работать будет.

KK>Сама же печка озвучена в исходном сообщении. Потребовалось обернуть семейство типов в общую обёртку. Конечно, этот конкретный пример несколько надуманный, но он помог мне узнать много нового.

Ну, вот только сейчас прозвучала реальная задача. Очень даже может быть, что эту задачу будет намного проще решить на макросах. Ведь для них написать пару десятков страниц кода не проблема. Было бы на основании чего их генерировать.

Макросы позволяют читать информацию о типах и генерировать по ней код. Причем информация о типах доступна не только для типов скомпилированных в сборки (как в случае использования рефексии), но и для кода определенного в проекте.

Вот здесь

Автор: VladD2
Дата: 24.09.11

лежит статья в которой есть пример такого макроса.