Меня когда-нибудь накажут.
Jan. 26th, 2010 09:15 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassПервое: вчера попросил заказчика, чтобы не приезжал - лень по морозу ехать в дебри его встречать а потом три дня по морозу ползать с ним по ресторанам. Я лучше поработаю. Совершенно неправильный подход, т.к. в нашем перевернутом с ног на голову миру социальные связи важнее чем технические решения и реальная работа вообще.
Второе: в проекте есть такая строчка:
Смысл - гуи проги отображает весьма сложный workflow по обработке диктантов, причем этот workflow состоит из не сильно большого числа повторяющихся операций, скомбинированных во всех мыслимых и немыслимых комбинациях. Причем каждой операции соотвествует хитрожопая комбинация GUI-контролов и пунктов меню. В итоге поведение GUI проги представляет собой граф, где вершины - текущие рабочие состояния, а ребра - переходы между ними, вызываемые юзером или автоматически сигналами от всяких фоновых потоков.
Поэтому, чтобы избежать копипасты, приходится из небольших классов, каждый из которых выполняет некую функцию и предоставляет для нее GUI(контролы, меню, взаимодействие с бэк-ендом) комбинировать один большой класс, который умеет все это до кучи и во взаимосвязи. Классы склеиваются генериками-комбинаторами, а взаимодействие делается дополнительными функциями или анонимными делегатами. И все это сделано таким образом, что создать класс "в неправильном состоянии" просто невозможно - не скомпилируется.
Цель - статическая проверка кошерности классов, потому что в предыдущей версии я неоднократно объебывался на том, что при переходе между состояниями GUI то поле не проинициализируешь, то оказывается, что тут нужный ресурс вообще нихрена не доступен и его нужно через цепочку из 20 вызовов тянуть параметром, и вообще это был ад.
Сейчас все идеально, но читабельность кода из-за генериков и анонимных делегатов сильно пострадала.
Второе: в проекте есть такая строчка:
class UIStateTranscribing:UIStateCombArity3<UIStateTranscribingBase, UIStateSoundBasePlayer, UIStateTextBase> {
...
}
Смысл - гуи проги отображает весьма сложный workflow по обработке диктантов, причем этот workflow состоит из не сильно большого числа повторяющихся операций, скомбинированных во всех мыслимых и немыслимых комбинациях. Причем каждой операции соотвествует хитрожопая комбинация GUI-контролов и пунктов меню. В итоге поведение GUI проги представляет собой граф, где вершины - текущие рабочие состояния, а ребра - переходы между ними, вызываемые юзером или автоматически сигналами от всяких фоновых потоков.
Поэтому, чтобы избежать копипасты, приходится из небольших классов, каждый из которых выполняет некую функцию и предоставляет для нее GUI(контролы, меню, взаимодействие с бэк-ендом) комбинировать один большой класс, который умеет все это до кучи и во взаимосвязи. Классы склеиваются генериками-комбинаторами, а взаимодействие делается дополнительными функциями или анонимными делегатами. И все это сделано таким образом, что создать класс "в неправильном состоянии" просто невозможно - не скомпилируется.
Цель - статическая проверка кошерности классов, потому что в предыдущей версии я неоднократно объебывался на том, что при переходе между состояниями GUI то поле не проинициализируешь, то оказывается, что тут нужный ресурс вообще нихрена не доступен и его нужно через цепочку из 20 вызовов тянуть параметром, и вообще это был ад.
Сейчас все идеально, но читабельность кода из-за генериков и анонимных делегатов сильно пострадала.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-01-27 12:19 am (UTC)Плавали-знаем. Текст в посте потвердил догадку =)
Я такую штуку использовал для сборки SDK под железяки с хуевой тучей подключаемых модулей - модули версионировал отдельно, а API для железяки собирал из схожим образом
no subject
Date: 2010-01-27 12:55 am (UTC)Пример как метациклические языки строятся.
Попробуй уже что ле LISP, а? =)