RAZOR & R#

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

А теперь рассмотрим задачу. Есть такая технология - называется RAZOR. Это такая сместь C# и HTML, которая отличается от ASP тем, что синтексические конструкции двух языков более или менее вложены друг в друга.

И мы имеем два пути. Мы можем свести все к C# и довольствоваться тем, что фичи будут работать там, где нет HTML. А еще мы можем сделать язык C# немного более открытым для новых синтаксических конструкций, реализовать для этих конструкций парсер, резолв, СFA, und so weiter... и, таким образом, получить платформу для поддержки C#-подобных языков и фичи, (такие как extract method) работающие на самом высоком уровне! Конкуренты - бойтесь!

у меня javascript.

В последнее время я много занимался поддержкой javascript. В основном, дело касалось code completion. Расскажу немного о трудностях, которые возникают, когда в языке отсутствуют типовые аннотации. Как ни странно это звучит, с решарпером javascript становится языком с довольно внушительной системой типов. Еще более странно будет звучать то, что все эти типы не используются для резолва, но обо всем по порядку.
Первое, что надо делать при поддержке любого языка - это построить кэш деклараций. В javascript нелокальными являются только свойства объектов. Существует бесчисленное (в прямом смысле этого слова) множество способов определить свойство в объекте. Начать можно с функции конструктора, для разминки поддержать микрософтовский RegisterNamespace("Jetbrains.ReSharper"), после чего можно сделать jQuery.Extend(). Для любителей пособирать декларации самостоятельно в этом месте все расширяемо и можно писать свои провайдеры.
Декларации просто так собирать не интересно, для каждого свойства хорошо бы знать его объемлющий класс (для которого это свойство может быть статическим или свойством объекта). Тут же собираем информацию о наследовании классов. Инвертируем полученную информацию об объемлющих классах и имеем основной источник информации об объеках и их свойствах.
Второй источник - это выражение, которым было проинициализировано свойство. Опять же, здесь есть место для тех, кто знает про типы выражений какие-то свои тайны.
А теперь главное: как представляется тип. Он почти всегда является наборов из нескольких типов, свойства которых объединяются. Самих же свойств довольно много:
1. Собственно свойства объекта. Пример: x.
2. Сигнатура (в случае если объект можно вызывать). Пример: x(1,2,3).
3. Тип возвращаемого значентя. Пример тот же.
4. Тип создаваемого объекта. Это значит что функция была конструктором. Пример: new x().
5. Базовый тип. Пример: x.prototype.
Вычисление типов может залезать довольно далеко в код и кэши, поэтому в вычислялке есть механизм кэширования и защита от зацикливаний. На посчитанных типах работает только комплишен и информация о параметрах. Для резолва тип квалификатора не используется, что мне кажется правильным. В ближайшем будущем я сделаю киллер фичу: create property from usage, которая станет третьим клиентом моей типизации javascript, а провыйдеры свойств я обяжу уметь создавать свойства которые они распознают. И теперь представьте себе, что расширение для jQuery можно будет сделать нажав alt+enter!

Плюс десять процентов к карме

Код комплишен остался где-то позади. Нет, про него никто не забыл, просто теперь он может жить своей новой и прекрасной жизнью самостоятельно, а я могу лишь радоваться тому, что за пару недель количество правил выросло на 10% до 110. Значит есть жизнь после рефакторинга и есть смысл двигаться дальше. 

А дальше идет еще более чудесный JavaScript, в котором из комментариев мы пытаемся извлекать информацию о типах, которой так не хватает человеку, избалованному строгими языками, пытаемся воплотить тысячу и одну идею облегчения жизни пользователям jQuery, полируем код комплишен и активно работаем с чудо-листочком, пытаясь ужать безграничную фантазию в 3 месяца сроку... Не знаю, почему я пишу слово 'мы'.

И вот в этой суете я задумался над одной вещью. Допустим, мы удалим поддержку js. Да, прямо сегодня мы стираем всю поддержку js и начинаем писать все заново. Мы укладываемся в 3 месяца? Ах, черт, боюсь что нет. Хотя это я считаю на одного человека. Если их будет двое? Уже более реалистично. А было ли это так же реалистично полгода назад?

У меня утро!

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

Не спрашивайте меня ничего, я пишу!

Я сказал сегодня, что не могу вспомнить, чем именно примечателен некий персонаж из пьесы, которую мы читали на английском на прошлой неделе. Отчасти это была правда, отчасти я надеялся на сочувствие, говоря, что у меня в голову загружен code completion и потребуется некоторое время чтобы освободить немного ресурсов для других задач. Но сочувствия я не нашел. Оказалось, что по мнению Н., мой мозг не обладает должной эластичностью и это качество мне необходимо развивать. Черт возьми, я этого совсем не ожидал! Действительно ли, погружаясь с головой в решение некоторой проблемы, какой бы сложной она не казалась, мы убиваем способность мыслить шире? Возможно ли, без потери эффективности, научиться мгновенно переключаться между разными задачами? 

Я не знаю ответ, но code completion дописал. Осталось сделать так, чтобы он заработал. Или взглянем шире... нужен ли нам code completion?      

двигаю гору code completion

На этой неделе, уходя домой, я каждый день прикреплял к стенке бумажку с количеством некомпилирующихся файлов. В последний раз написал 19. А в течение недели это число временами превышало 100.
Теперь я знаю, как делается code completion, а точнее как он будет делаться, когда все взлетит. Вот некоторые предварительные итоги.
Теперь в решарпере 4 вида code completion: basic, automatic, import и smart.  И здесь у нас первое достижение - ничто не мешает сделать новый пятый вид, если кто-то придумает что он будет делать. Кстати, почему бы не сделать дважды умный или дважды импортирующий code completion? В коде такая гибкость выражается не только открытым множеством значений видов code completion, но и декларативным стилем проверок этих значений.
Автоматический code completion является обособленным видом, так как, в отличие от его родственников, он связан с некоторой сессией, время жизни которой определяется довольно сложно и зависит от печати кода, показаных lookup окошек и асинхронного построителя синтаксического дерева. Опять же, сейчас стало понятно, что управление этой сессией надо выносить в отдельную компоненту.
Теперь немного о дизайне. Программном.
Все просто: есть два набора компонент. Первый набор отвечает за создание контекста. Обычно на каждый язык приходится по одному такому контексту. Сложность контекста определяется серьезностью намерений реализовать хороший и быстрый code completion. Сейчас в c# контекст сложный, а в некоторых языках тривиальный. Но это мы исправим.
Имея набор контекстов, мы берем второй набор компонент - правила добавления и изменения списка completion item-ов. Каждое правило состоит из следующих стадий: подготовка, добавление новых элементов, редактирование списка элементов с возможностью удаления существующих и добавлением новых, декорация или изменение атрибутов элементов, определение стиля показа lookup окошка и опций автоматического применения. Все стадии выполняются последовательно для всех правил преобразования.
Некоторый примеры стадий:
1. С подготовкой все понятно.
2. Добавление ключевых слов или live template item-ов.
3. Собственно, замена ключевых слов на омонимичный live template item-ы.
4. Замена методов со скобочками на методы без скобочек в месте, где ожидается делегат.
5. Тоже нечего сказать.
Итого, мы имеем расширяемый по технологиям, изменяемый в пределах одной технологии и, к тому же, быстро работающий code completion. Правильно?

code completion

Что больше влияет на качество программного продукта? Продуманность и мощь ядра, или отполированная до блеска функциональность фич для конечных пользователей? Очевидно, что многие фичи Решарпера были бы невозможными без мощной поддержки со стороны ядра, но также очевидно, что все достоинства космической архитектуры могут быть сильно испорчены неаккуратной реализацией фич. Хорошим примером листовой фичи, требующей особой аккуратности, является код комплишен.

Трудно подсчитать количество времени, которое потребовалось для того чтобы реализовать комплишен в C#. Думаю, что это многие месяцы работы.

Сейчас в Решарпере поддерживается более десятка различных языков, и во всех них хочется иметь такой же отшлифованный код комплишен как и в C#. Да, реализовывать его в разных языках будут разные люди, и задача у них будет сложнее, так как многие технологии, которые мы поддерживаем сейчас напрямую не используются нами, а значит продумывать поведение нужно будет буквально в воздухе!

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

Собственно, созданием общей инфраструктуры код комплишена я и буду заниматься в ближайшее время. Посмотрим, что получится.