На этой неделе, уходя домой, я каждый день прикреплял к стенке бумажку с количеством некомпилирующихся файлов. В последний раз написал 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, а точнее как он будет делаться, когда все взлетит. Вот некоторые предварительные итоги.
Теперь в решарпере 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. Правильно?
No comments:
Post a Comment