metaclass | Меня когда-нибудь накажут.

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

Второе: в проекте есть такая строчка:

class UIStateTranscribing:UIStateCombArity3<UIStateTranscribingBase, UIStateSoundBasePlayer, UIStateTextBase> {
...
}

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

Поэтому, чтобы избежать копипасты, приходится из небольших классов, каждый из которых выполняет некую функцию и предоставляет для нее GUI(контролы, меню, взаимодействие с бэк-ендом) комбинировать один большой класс, который умеет все это до кучи и во взаимосвязи. Классы склеиваются генериками-комбинаторами, а взаимодействие делается дополнительными функциями или анонимными делегатами. И все это сделано таким образом, что создать класс "в неправильном состоянии" просто невозможно - не скомпилируется.

Цель - статическая проверка кошерности классов, потому что в предыдущей версии я неоднократно объебывался на том, что при переходе между состояниями GUI то поле не проинициализируешь, то оказывается, что тут нужный ресурс вообще нихрена не доступен и его нужно через цепочку из 20 вызовов тянуть параметром, и вообще это был ад.

Сейчас все идеально, но читабельность кода из-за генериков и анонимных делегатов сильно пострадала.