Обновленный ISBL-редактор в DIRECTUM 5.1
К старому редактору вычислений накопилось большое количество пожеланий. При разработке кода возникали неудобства, и разработчику приходилось часто обращаться к справке или компонентам системы, например, Типы карточек документов. А цветовая схема редактора попросту устарела. Мы рады вам представить обновленный ISBL-редактор системы DIRECTUM 5.1.
Цветовые схемы
ISBL-редактор и отладчик обзавелись новыми цветовыми схемами. Реализованы две: светлая и темная.
Подсказка по объектной модели
Этого так долго ждали все, кто хоть раз разрабатывал свой код на ISBL:
Мы реализовали подсказки по объектной модели IS-Builder. Они появляются в ситуациях, когда:
- автодополнение кода играет важную роль: при вводе свойства или метода объекта и его параметров;
- необходимо быстро посмотреть, какие свойства и методы имеет объект;
- требуется обратиться к реквизиту объекта.
Реквизиты часто имеют незначимые имена, поэтому разработчику приходилось обращаться к компонентам Типы справочников и Типы карточек документов для того, чтобы посмотреть имя и заголовок нужного реквизита. Сейчас все это можно посмотреть в подсказке, в том числе найти нужный реквизит по его заголовку.
Также подсказка отображает параметры методов:
Теперь разрабатывать код гораздо проще и быстрее.
Тип интерфейсных переменных
Для отображения подсказки по объектной модели редактору вычислений необходимо знать тип переменной ISBL.
Система пытается автоматически определить тип переменной. Тип будет успешно определен:
- если вычисление начинается с предопределенных переменных, например, EDocuments, References;
- если вычисление начинается с системной функции, например, CreateReference().
Несмотря на то, что редактор знает тип переменной, определить тип справочника и тип карточки документа он не может.
В некоторых случаях тип переменной для подсказки Code Insight не определяется автоматически, так как на момент написания кода ISBL-редактору неизвестны значения переменных:
- результат вызова прикладной функции – это всегда простой тип данных или Variant;
- некоторые свойства объектной модели возвращают значения типа Variant, так как в них могут храниться значения произвольного типа, например, IObject.Environment;
- некоторые свойства объектной модели возвращают значения базового типа данных, например, ICustomJob, IObjectInfo, а разработчику нужно работать с объектом конкретного типа-наследника.
Поэтому в язык ISBL была добавлена возможность указать вручную тип интерфейсных переменных для отображения подсказки по объектной модели IS-Builder.
Пример указания типа:
Doc: IEDocument.ПЭА = EDocuments.CreateNewFromTemplate("ПЭА"; "Г000018"; "Г000059")
В примере указание типа карточки документа для переменной Doc позволяет также отображать в подсказке к переменной реквизиты указанного типа карточки документа:
Подробнее о переменных ISBL и объявлении типа для них см. справку.
А также:
Для удобства на ленту редактора вычислений были вынесены действия по блочному комментированию и для сдвига текста кода, а также доработаны горячие клавиши.
Мы исправили дефекты и реализовали пожелания, например, в компоненте Сценарии на ленту добавлена кнопка Текст, которая открывает редактор вычислений сценария. Таким образом, текст сценария можно изменять, не открывая его карточки.
На этом новинки DIRECTUM 5.1 в области разработки не заканчиваются. Подробности в следующих статьях!
То есть, по сути введена не строгая типизация?
Введена необязательная типизация для интерфейсных переменных. Цели Александр написал в статье.
Без неё полноценный механизм подсказок сделать бы не получилось, т.к. не в 100% случаев тип переменной может быть корректно определен автоматически.
При подсказке имен реквизитов справочников в списке отражаются реквизиты, которые настроены через справочник "Настройки дополнительных реквизитов справочников"? Или только те, которые явно указаны в справочнике?
Юлия, да, дополнительные реквизиты справочников в подсказке отображаются
На мой взгляд, не очень удачно сделали типизацию, из-за нее код написанный на 5.1 придется редактировать, чтобы он работал на более ранних версиях системы. Почему, например, было не сделать указание типа в комментарии над переменной? Как это работает в PHPStorm'е (может это стандарт, не знаю):
// @var doc IEDocument.ПЭА Doc = EDocuments.CreateNewFromTemplate("ПЭА"; "Г000018"; "Г000059")И наглядно, и в старых версиях бы на ура работало, и подсветку сделать можно было бы. Можно было определенный формат сделать, например, три слеша, а не два, чтобы удобнее было парсеру.
Андрей, при выходе новой версии мы задумываемся над тем, чтобы при конвертации старой версии было как можно меньше несовместимостей. Задачи обеспечить переносимость нового функционала в старые версии нет, это касается и ISBL-кода (например, в каждой версии появляются новые функции и расширяется объектная модель).
Предлагаемый вами вариант рассматривался, от него мы отказались в пользу типизации и в runtime, и в designtime по следующим причинам:
Типизация переменных - вещь не обязательная, CodeInsight во многих случаях работает и без неё. Для чего вам хотите переносить написанный код из 5.1 в более старые версии?
Это очевидно: ту разработку, которой я бы хотел поделиться с сообществом. Или техническое решение, будь я партнером.
Я обе причины не понял. Какая разница, как делать объявление переменной? Настроить интерпретатор, чтобы он не просто отбрасывал комментарии, а читал, допустим, до третьего знака. Сделать тогда формат объявления переменной
В чем тут принципиальная разница с уже существующим вариантом? В чем сложность сделать потом полноценную runtime-типизацию на основе указания типа в полукомментарии?
Мне правда интересно, я, наверное, чего-то не знаю, сильно в устройство интерпретаторов не углублялся.
И потом, используемый вариант сейчас ухудшает читабельность, по сравнению с тем, что типизация использовалась бы в комментарии. Человек отличается от интерпретатора тем, что он умнее и видит полную картину без подсказок, а указание типа - это по большей части лишь служебная информация, нужная именно интерпретатору, а не разработчику. В дотнете, например, автоматический вывод переменной был одним из серьезных шагов вперед в области читабельности, я считаю. Сравните, например:
и
А информация, указанная в комментарии, при беглом просмотре кода все равно отфильтровывалась бы.
Я не думаю, что получится совсем обходиться без нее обходиться, если захочется комфортной работы.
Откровенно говоря, не такое уж глобальное влияние в каждой версии оказывает на всю разработку расширение объектной модели (новые прикладные функции замечательно экспортируются). В 5.1, если я правильно понимаю, из таких изменений - это только древовидное отображение в диалоге. Трудно, конечно, сказать, в скольких сценариях это окно будет использоваться, но явно даже не 10%.
Кроме того, при разработке новых технических решений партнерам будет невыгодно затачивать разработку под самые новые версии - по возможности все равно лучше охватывать побольше версий, чтобы окупать разработку. Т.е. в примере с тем же древовидным окном, если разрабатывается техническое решение партнера, в первую очередь будут рассмотрены альтернативные варианты реализации, т.е. в общем случае широкое использование новой непереносимой разработки будет еще несколько ниже.
Для себя принял решение, что типизацией переменных пользоваться не буду по причинам, описанным выше в обсуждении. Я так понял, что это нужно только для того, чтобы правильно отобразилась подсказка Code Insight, а это того не стоит. Жили как-то без этого 11 лет и похоже придется дальше жить. Реализация, конечно, просто убила...
Дмитрий, а вы в работе механизм попробовали? Еще раз повторю, что в большинстве случае CodeInsight не требует типизации переменных.
Андрей, дело не только в объектной модели. Например, в 5.0 появились ленты, в предыдущих версиях разработка такого справочника не заработает 4.9.1.
Если следовать этой логике, развитием возможностей DIRECTUM вообще не стоит заниматься. Применительно к языкам программирования - практически в любых из них со временем появляются новые языковые конструкции; код с ними, естественно, несовместим с предыдущими версиями.
X: IReference
....
X = 123 // либо другое значение, несовместимое с IReference
Такой код будет прекрасно работать с design-time типизацией, и сразу же приведет к ошибке при появлении runtime-типизации. С учетом того, что во многих ISBL-вычислениях сотни строк кода, ситуация окажется не такой уж и редкой.
Дмитрий, я не случайно начал свой пост с цитаты из статьи:
Т.е. если подсказка сработает правильно, то хорошо, если нет, не обращаем на нее внимания. Специально изменять код, чтобы она всегда отображалась правильно, я не буду.
Ну да, еще сколько-то процентов разработки надо адаптировать. Не всю.
Дмитрий, вообще-то единственным смыслом моих постов было то, что реализацию можно было сделать лучше, а не то, что улучшениями заниматься нельзя.
А сейчас так нельзя сделать?
Имеется в виду, что с данным вариантом реализации типизации переменных область разработки, которую надо адаптировать, увеличилась еще больше, хотя этого можно было избежать, на мой взгляд.
Сейчас при выполнении такого кода будет ошибка, т.к. тип проверяется и при выполнении (в runtime).
Согласен. Но если такая проблема все-таки встанет - вполне возможно (силами сообщества) написать утилиту, которая автоматически удалит операции объявления типа.
Т.е. сейчас интерпретатор понимает объявление типизированной переменной вида "varname: vartype". В чем сложность настроить интерпретатор, чтобы он понимал объявление типизированной переменной, например, вот так "//! varname: vartype" ?
И почему вы говорите, что
В чем сейчас неполноценность runtime-типизации, если присвоение, как вы сказали, неправильного типа уже сейчас вызовет ошибку?
Сложность заставить интерпретатор понимать как вы предлагаете не сильно отличается от сложности того, как сделали. Но кроме сложности реализации есть еще куча разных факторов: расширяемость, понятность для старых разработчиков, понятность для новых разработчиков, обратная совместимость, прямая совместимость, удобство использования, и т.п. По результатам этого всего (явно или неявно) и выбирается вариант реализции.
Вы же уперлись только в прямую совместимость, которая вообще не часто бывает целью при разработке языков программирования.
Отнюдь. Не вижу в приведенных вами критериях ни одного, которым бы не удовлетворял предложенный мной вариант типизации.
И, как я уже писал, текущий вариант типизации мало того, что ломает пресловутую прямую совместимость, он еще и хуже для чтения, просто потому, что это лишняя деталь. Тип переменной человеку и так понятен из контекста, и нужна эта техническая деталь только интерпретатору.
Речь шла про вариант "сделать проверку типов только в designtime". Сейчас сделан полноценный вариант.
Андрей, ваше предложение про типизацию понятно. Сейчас мы его рассматривать к реализации не будем, т.к. поддерживать два разных способа задания типа переменных - очевидно плохой вариант. Если проблема переносимости разработки в старые версии встанет остро - вернемся к этому вопросу.
Вот именно, что уперлись и потому не видите.
Расширяемость: если сейчас тип переменной ради прямой совместимости задавать через комментарии, то это значит, что и будущие новые возможности надо будет делать через комментарии. Причем с каждым разом это будет всё сложнее и сложнее (не забываем про прямую совместимость).
Понятность для старых разработчиков: примерно одинаковая с небольшим плюсом у текущей реализации, т.к. задание поведения через код логичнее чем через комментарии.
Понятность для новых разработчиков: значительно понятнее текущий вариант.
Обратная совместимость: одинаково.
Прямая совместимость: текущий вариант хуже предложенного.
Этих параметров целая куча, причём добрая часть из них не формализируется в проектах, а лежит в головах у разработчиков, а часть из них я и вовсе назвать не могу т.к. это внутренняя кухня компании и не подлежит разглашению.
А теперь я прошу дать хотя бы один пример того, что еще можно встроить в ISBL. Лямбда-функции, классы/наследование/инкапсуляция/полиморфизм, чистые функции? Что еще, вы считаете, не хватает в языке?
Мой ответ - язык больше трогать не надо. Для своих задач он подходит, для чего-то большего надо уже не придумывать велосипед, а брать уже существующие языки.
Поэтому аргумент "Расширяемость" мы убираем - в обозримой перспективе язык изменяться не будет.
Как я уже упоминал - типизация нужна только интерпретатору (кстати, давайте еще обсудим, зачем из фишки "подсказка в design-time" сделали runtime-типизацию - это для чего вообще?). Опытному разработчику строка
Doc = EDocuments.CreateNewFromTemplate("ПЭА"; "Г000018"; "Г000059")проще и яснее, чем
Doc: IEDocument.ПЭА = EDocuments.CreateNewFromTemplate("ПЭА"; "Г000018"; "Г000059")т.к. во второй строке информация дублируется. Сначала для интерпретатора, потом то, что там реально делается.
А теперь разберем по косточкам. Только давайте условимся, что под новыми разработчиками мы имеем в виду не бабу Глашу - уборщицу, а разработчика, который в какой-то степени уже имеет навык разработки - таких все равно большинство (даже админы все равно будут иметь какие-то навыки написания консольных команд). И вот этот новичок видит перед собой текст скрипта на ISBL, в котором то и дело проскакивает указание типа. И с каким опытом это соотносить? Давайте возьмем самые распространенные языки: Javascript - нет указания типа вообще, JAVA/C#/С/С++ - указание типов всех переменных, Pascal/Delphi - указание типов всех переменных, PHP/Python - без типов (редкие исключения брать не будем в расчет) и так далее.
И вот тут - то тип, то нет. То тип, то нет. Возникает логичный вопрос: А ЗАЧЕМ (да, вот такими большими буквами)? Да, более опытные разрабы дотумкают, что это указание типа для интерпретатора, правда непонятно - это вообще обязательно или нет и в каких случаях (а до того, что скрипт представляет из себя в runtime наполовину типизированного, наполовину нетипизированного франкенштейна, они дотумкают позже - на ошибках)?
Вы правда считаете, что указание типа переменной в блоке комментариев где-нибудь в начале скрипта - это менее наглядно, чем рандомное тыкание типов прямо в коде в общем нетипизированном языке?
Это очень-очень плохо и я надеюсь, не надо объяснять - почему.
Полностью солидарен с данным высказыванием.
Зачем мне сейчас выдумывать, что следует ещё добавить в язык? Гораздо легче предусмотреть возможность, чтобы добавить в принципе можно было и это не приводило к большим усложнениям. Вы же предлагаете не просто не предусматривать, а ещё и зарубить такую возможность аргументируя только своим мнением.
А вот если такой пример?:
Теперь давайте не привязываясь к языку выясним, нормально ли то, что компилируемые/интерпретируемые команды находятся в комментариях? Насколько разработчикам, тем более опытным и пришедшим с других языков, должна импонировать такая идея? И я правильно понимаю, что эту сентенцию - "комментарии должны игнорироваться интерпретатором" вы предлагаете вставлять в каждый проект, а не держать в голове?
Особенно странно выглядит ваша обида в свете того, что пользоваться принудительным указанием типа не обязательно, раз уж оно так не нравится. Вот мне нравится, я пользуюсь.
В других языках, которыми я пользуюсь, тоже постоянно появляются новые возможности, изменяется синтаксис. Только вот все новое почему-то не в комментариях описывается...
А мне не нравится такой способ указания типа переменной и он не является для меня интуитивно понятным.
Мне гораздо проще понять тип переменной, если бы это выглядело, например, так:
И уж если указывать тип переменной, то надо указывать его у всех переменных в коде. Все равно, как я понял, обратной совместимости кода нет, без дополнительных манипуляций над текстом кода. А то получается полный бардак и код становится читать значительно труднее (особенно с таким способом указания типов переменных).
Я понимаю, что сейчас никто ничего переделывать не будет, но и таким способом указания типа переменных я пользоваться не хочу. Благо повезло, что это делать не обязательно.
Преждевременная оптимизация, как известно зло. И зачем аргументировать добавлением новых возможностей, если добавлять нечего?
Вы переходите рамки хамства (не первый раз, кстати), пытаясь за меня описать мое состояние. Попытайтесь, пожалуйста, обходиться без этого. Я лишь высказываю свое мнение, если вы где-то увидели обиду, упертость или что-то еще, то это только ваши домыслы.
Вы знаете, почему пишут ? Зачем впереди восклицательный знак?
А что, комментарии не должны игнорироваться интерпретатором?
Дмитрий, мы рассматривали каждый из предлагаемых вами вариантов. Напомню, что тип можно объявить и без инициализации значения, если вариант с инициализацией кажется вам не понятным.
Критерии выбора варианта:
// Такой вариант сложнее для разработчика на ISBL - надо // писать лишние конструкции Dim и As. Dim Doc As IEDocument: GetBlaBlaBla(CurrentUser) // Рассматривали этот вариант, но он было сложнее в реализации. IEDocument Doc = GetBlaBlaBla(CurrentUser) // То же самое - без var можно обойтись. var Doc: IEDocument = GetBlaBlaBla(CurrentUser)Считаю, что вариант нами был выбран удачно:
Почти убедили :)
Я почему-то с надеждой жду, когда разработку можно будет вести на не ISBL (или не только на ISBL), а на каком-нибудь существующем языке программирования.
Вот это я понимаю, и все предложенные варианты для меня примерно одинаковы в восприятии, хотя есть и фавориты. Но там нет предложений писать тип в комментариях. А обратная совместимость есть, старый код продолжает работать в новой системе. Прямой совместимости нет (новый код может не работать в старой системе).
Преждевременная оптимизация безусловно зло, как минимум в 97% случаев :) Только причем тут она? Я про оптимизацию и тем более преждевременную ничего не говорил.
Про хамство - извините, если обидел, постараюсь избегать этого.
DOCTYPE знаю, про восклицательный знак не задумывался, теперь прочитал. Только он не признак комментария, комментарий там все же немного по-другому обозначается.
Конечно должны, об этом я и толкую! Это просто пример того, о чем можно не упоминать в _не_первом_ проекте, связанном с интерпретатором.
По поводу добавлять нечего: моя воля я бы понадобавлял %) Например мне сильно не хватает оператора, который позволял бы не двигаться по цепочке Application.ServiceFactory.GetUserByID(..).Name в случае, если встретился пустой элемент. В C# это можно записать как Application?.ServiceFactory?.GetUserByID(..)?.Name.
Из предыдущих добавлений всегда использую try...except вместо старого ExceptionsOff().
Модификация языка с прицелом на непонятное будущее (для меня, впрочем, понятное - добавлять в язык больше нечего, для других целей нужен другой язык) - это и есть преждевременная оптимизация [конструкций языка].
Вот как раз для совместимости со старыми браузерами он и ставится, т.к. раньше комментарий обозначался . Когда-то даже скрипты заключали в эти символы, чтобы они не вываливались в неизменном виде пользователям, у которых браузеры эти скрипты не поддерживают.
Странно, что не стали ломать совместимость со старыми браузерами.
Как же тогда получается так, что PHPStorm читает в комментариях в design-time типы переменных - так работает code insight, и этим пользуются разработчики? Это неправильно?
Про реализацию try...except тоже уже говорили.
foreach .. in .. и обработка ошибок были теми недостающими кирпичиками, которые добавили не так давно, и больше никаких модификаций языка на горизонте не видно.
Та преждевременная оптимизация, про которую существует расхожее выражение, что она зло, не имеет никакого отношения, к тому, что вы под ней понимаете.
По PHPStorm ничего сказать не могу, с PHP не работаю, однако в ваших силах написать _сторонний_ редактор, который будет понимать подсказки из комментариев. Прямо как PHPStorm.
Про необходимость будущих модификация языка со своей стороны завязываю, я вижу, куда можно развиваться, вы - нет, это пустой спор, каждый останется при своём мнении.
Смотрите на вещи шире.
Да. Но рыться по стандартам сейчас, извините, не буду, это не принципиально.
Но судя по всему, работаете в VS, раз вам известны конструкции С#. Вам известен комментарий вида ///, который ставится перед методом, классом и так далее, из которого IDE читает текстовое описание и потом использует в подсказках? Как же IDE не пропускает эти комментарии? Почему в Microsoft не считают, что комментарии должны восприниматься только как комментарии?
Почему же - я тоже вижу. Например, вместе с ISBL использовать, например, Python. Вопрос не в "видеть", а в реальной необходимости и, главное, возможности модификации языка.
Доброго дня, недавно стал разрабатывать справочник на новой версии, я просто в восторге от того как теперь легко в обработчиках писать реквизиты для текущего ТС. Да и вообще подсказки работают в разы лучше чем раньше. При этом ни разу не пользовался типизацией (не привык пока к ней), все и так работает, так что коллеги не понимаю о чем вообще спор. Стало лучше, спасибо.
C VS работаю, там действительно есть такого рода документация, да впрочем и в других средах разработки она есть. Но это именно, что документация, она не компилируется в бинарник и не участвует в работе кода.
Идеальная схема для скриптовых языков. Теперь можно еще объяснить, зачем была сделана runtime-типизация?
А зачем надо было придумывать какой-то "язык", а не использовать тот же VBA или JavaScript?
Быть может потому, что JavaScript в те времена ещё не было, а VBA принадлежит MS.
Авторизуйтесь, чтобы написать комментарий