Поковырял ещё некоторое время в Drat, идея хорошая, но многие вещи, так скажем, не понятны.
Хочу обсудить концепцию метаданных. Которой я всё пытался найти применение и мне кажется в ней что-то есть, но реализация доступа к метаданным — из рук вон плоха. Особенно для нового языка, который должен был учесть существующий опыт и т.д. и т.п.
Т.е. если вы из питона (как я) то поведение у этой системы прямо противоположное предполагаемому. Это не декораторы и проще всего к ним доступаться из декорируемого (аннотируемого) объекта (функции, класса и т.п.). Ну проще — это образно. На самом деле надо совершить три действия чтоб получить значение — получить зеркало объекта (InstanceMirror), из зеркала объекта получить зеркало класса объекта (ClassMirror) и уже в его метаданных искать то, что мы запихали в метаданные объекта…
Решение же через эту систему метаданных типичных проблем, решаемых декораторами и вовсе выглядит неразумным. К примеру есть фреймворк bloodless, который, как пишет автор, глубоко вдохновлён питоновским Flask'ом. Там через метаданные задаётся роутинг, перехватчики запросов и обработчики ошибок… Т.к. при задании метаданных не происходит вообще ничего кроме создания самих метаданных — единственный способ собрать то, к чему они прикреплены — перебрать ВСЁ! И здесь так и сделано — в цикле перебираются зеркала всего в области видимости, у каждого инстанса ищутся метаданные и проверяются на соответствие нужным типам метаданных…
Т.е. мне кажется это, мягко выражаясь, не правильно — метаданные явно не для этого.
Как я понимаю они скорее для точечной проверки. Т.е. когда у объекта могут быть определённые метаданные согласно API, рекомендациям и т.п. Например функции вышеупомянутого роутинга с метаданными по методам/урлам/типам собрать в список руками и засунуть в конфигуратор. Конфигуратор знает какие метаданные ожидать от функций и формирует таблицу роутинга. Ну, как пример…
Автор: qnub
