Eclipse како технолошка платформа за 1C: Enterprise Development Tools

Веројатно, Затемнувањето одамна нема потреба од посебен вовед. Многу луѓе се запознаени со Eclipse благодарение на алатките за развој на Eclipse Java (ЈДТ). Токму овој популарен Java IDE со отворен код, повеќето програмери го поврзуваат со зборот „Eclipse“. Како и да е, Eclipse е и проширлива платформа за интегрирање на развојни алатки (Eclipse Platform), и голем број IDE изградени врз основа на неа, вклучувајќи го и JDT. Eclipse е и Eclipse Project, проект на највисоко ниво кој го координира развојот на Eclipse Platform и JDT, и Eclipse SDK, испорачаниот резултат од тој развој. Конечно, Eclipse е Фондација со отворен код со огромна заедница на проекти, од кои не сите се напишани во Java или поврзани со развојни алатки (на пример, проекти Eclipse IoT и Наука за затемнување). Светот на Eclipse е многу разновиден.

Во оваа статија, која е по природа преглед, ќе се обидеме да погледнеме некои од основите на Eclipse архитектурата како платформа за градење интегрирани развојни алатки и да дадеме почетна идеја за компонентите на Eclipse кои ја формираат основата на технологијата. платформа за „новиот конфигуратор“ 1C: Enterprise. 1C: Алатки за развој на претпријатија. Се разбира, таквиот преглед неизбежно ќе биде во голема мера површен и прилично ограничен, вклучително и затоа што не се фокусираме само на програмерите на Eclipse како целна публика. Сепак, се надеваме дека дури и искусните програмери на Eclipse ќе можат да најдат интересни информации во статијата. На пример, ќе зборуваме за една од „тајните на затемнувањето“, релативно нов и малку познат проект Eclipse Handly, која беше основана и поддржана од 1C.

Вовед во Eclipse Architecture

Ајде прво да погледнеме некои општи аспекти на архитектурата на Eclipse користејќи го примерот Алатки за развој на Eclipse Java (ЈДТ). Изборот на JDT како пример не е случаен. Ова е првата интегрирана развојна околина што се појавува во Eclipse. Други *DT Eclipse проекти, како што е Eclipse C/C++ Development Tooling (CDT), беа креирани подоцна и ги позајмуваат и основните архитектонски принципи и индивидуалните фрагменти од изворниот код од JDT. Основите на архитектурата утврдени во JDT се релевантни до денес за речиси секој IDE изграден на врвот на платформата Eclipse, вклучувајќи ги и 1C: Enterprise Development Tools.

Пред сè, треба да се забележи дека Eclipse се карактеризира со прилично јасно архитектонско слоевитост, со одвојување на функционалноста независна од јазикот од функционалноста дизајнирана да поддржува одредени програмски јазици и одвојување на „јадрените“ компоненти независни од UI од компонентите поврзани со помошен кориснички интерфејс.

Така, платформата Eclipse дефинира заедничка инфраструктура независна од јазикот, а алатките за развој на Java додаваат целосно опремен Java IDE на Eclipse. И платформата Eclipse и JDT се состојат од неколку компоненти, од кои секоја припаѓа или на „јадро“ независно од UI или на слој на интерфејс (Слика 1).

Ориз. 1. Eclipse Platform и JDT

Ајде да ги наведеме главните компоненти на платформата Eclipse:

• Траење — Ја дефинира инфраструктурата на приклучокот. Затемнувањето се карактеризира со модуларна архитектура. Во суштина, Eclipse е збирка на „продолжни точки“ и „екстензии“.
• Работен простор — Управува со еден или повеќе проекти. Проектот се состои од папки и датотеки кои се мапирани директно во датотечниот систем.
• Стандарден прибор со алатки (SWT) - Обезбедува основни елементи на корисничкиот интерфејс интегрирани со оперативниот систем.
• JFace — Обезбедува голем број рамки за интерфејс изградени врз SWT.
• алатки — Ја дефинира парадигмата на Eclipse UI: уредници, погледи, перспективи.

Мора да се каже дека платформата Eclipse обезбедува и многу други корисни компоненти за градење интегрирани развојни алатки, вклучувајќи Debug, Compare, Search и Team. Посебно треба да се спомене JFace Text - основата за градење „паметни уредници“ на изворниот код. За жал, дури и површно испитување на овие компоненти, како и на компонентите на слојот на корисничкиот интерфејс, не е возможно во рамките на овој напис, така што во остатокот од овој дел ќе се ограничиме на преглед на главните „јадрени“ компоненти на платформата Eclipse и JDT.

Основно траење

Инфраструктурата на приклучокот Eclipse се заснова на OSGi а предвидени со проектот Eclipse Equinox. Секој приклучок Eclipse е пакет OSGi. Спецификацијата OSGi ги дефинира, особено, механизмите за верзии и решавање на зависности. Покрај овие стандардни механизми, Equinox го воведува концептот точки на проширување. Секој приклучок може да дефинира свои точки за проширување, а исто така да воведе дополнителна функционалност („екстензии“) на системот користејќи точки за проширување дефинирани од истите или други приклучоци. Секој детален опис на механизмите OSGi и Equinox е надвор од опсегот на овој напис. Само да забележиме дека модуларизацијата во Eclipse е целосна (било кој потсистем, вклучувајќи го и Runtime, се состои од еден или повеќе приклучоци), и речиси сè во Eclipse е екстензија. Покрај тоа, овие принципи беа вградени во архитектурата Eclipse долго пред воведувањето на OSGi (во тоа време тие користеа сопствена технологија, многу слична на OSGi).

Основен работен простор

Речиси секоја интегрирана развојна средина изградена на врвот на платформата Eclipse работи со работниот простор на Eclipse. Тоа е работниот простор кој обично го содржи изворниот код на апликацијата развиена во IDE. Работниот простор се мапира директно на датотечен систем и се состои од проекти кои содржат папки и датотеки. Овие проекти, папки и датотеки се нарекуваат ресурси работен простор. Имплементацијата на работниот простор во Eclipse служи како кеш во однос на датотечниот систем, што овозможува значително да се забрза преминувањето на дрвото на ресурсите. Покрај тоа, работниот простор обезбедува голем број дополнителни услуги, вклучувајќи механизам за известување за промени на ресурсите и инкрементална градежна инфраструктура.

Компонентата Core Resources (приклучок org.eclipse.core.resources) е одговорна за поддршка на работниот простор и неговите ресурси. Особено, оваа компонента обезбедува програмски пристап до работниот простор во форма модели на ресурси. За да работат ефективно со овој модел, на клиентите им треба едноставен начин да прикажат врска до ресурс. Во овој случај, би било пожелно да се скрие објектот што директно ја складира состојбата на ресурсот во моделот од пристап на клиентот. Во спротивно, во случај на, на пример, бришење датотека, клиентот би можел да продолжи да држи објект што повеќе не е во моделот, со проблемите што следуваат. Eclipse го решава овој проблем користејќи нешто наречено се справи со ресурс. Рачката делува како клуч (ја знае само патеката до ресурсот во работниот простор) и целосно го контролира пристапот до внатрешниот објект на моделот, кој директно складира информации за состојбата на ресурсот. Овој дизајн е варијација на моделот Рачка/Тело.

Ориз. Слика 2 го илустрира идиомот Рачка/тело како што се применува на моделот на ресурси. Интерфејсот IResource ја претставува рачката на ресурсот и е API, за разлика од класата Resource, која го имплементира овој интерфејс, и класата ResourceInfo, која го претставува телото, кои не се API. Нагласуваме дека рачката ја знае само патеката до ресурсот во однос на коренот на работниот простор и не содржи врска до информациите за ресурсите. Објектите со информации за ресурсите формираат таканаречено „елементно дрво“. Оваа структура на податоци е целосно материјализирана во меморијата. За да се најде примерот на информации за ресурсите што одговара на рачката, дрвото на елементите се поминува според патеката зачувана во таа рачка.

Ориз. 2. IRResource и ResourceInfo

Како што ќе видиме подоцна, основниот дизајн на моделот на ресурси (можеме да го наречеме базиран на рачка) се користи во Eclipse и за други модели. Засега, да наведеме некои од карактеристичните својства на овој дизајн:

• Рачката е предмет на вредност. Вредносните објекти се непроменливи објекти чија еднаквост не се заснова на идентитет. Таквите предмети можат безбедно да се користат како клуч во хаширани контејнери. Повеќекратни примероци на рачка може да упатуваат на истиот ресурс. За да ги споредите, треба да го користите методот equals(Object).
• Handle го дефинира однесувањето на ресурсот, но не содржи информации за состојбата на ресурсот (единствениот податок што го складира е „клучот“, патеката до ресурсот).
• Рачка може да се однесува на ресурс што не постои (или ресурс што сè уште не е создаден или ресурс што веќе е избришан). Постоењето на ресурс може да се провери со помош на методот IResource.exists().
• Некои операции може да се имплементираат само врз основа на информациите зачувани во самата рачка (т.н. операции само со рачка). Примери се IResource.getParent(), getFullPath(), итн. Ресурсот не треба да постои за да успее таквата операција. Операциите за кои е потребен ресурс да постои за да успеат, фрлаат CoreException доколку ресурсот не постои.

Eclipse обезбедува ефикасен механизам за известување за промените во ресурсите на работниот простор (Слика 3). Ресурсите може да се променат или како резултат на дејства извршени во самиот Eclipse IDE или како резултат на синхронизација со датотечен систем. Во двата случаи, на клиентите кои се претплатиле на известувања им се обезбедуваат детални информации за промените во форма на „делта на ресурси“. Делта ги опишува промените помеѓу две состојби на (под)дрвото на ресурсите на работниот простор и самата е дрво, чијшто јазол опишува промена на ресурс и содржи листа на делти на следното ниво кои ги опишуваат промените на детските ресурси.

Ориз. 3. IResourceChangeEvent и IResourceDelta

Механизмот за известување базиран на делта на ресурси ги има следните карактеристики:

• Една промена и многу промени се опишани со користење на истата структура, бидејќи делтата е изградена според принципот на рекурзивен состав. Клиентите на претплатниците можат да обработуваат известувања за промена на ресурсите користејќи рекурзивно спуштање низ дрво на делти.
• Делтата содржи целосни информации за промените на ресурсот, вклучувајќи го неговото движење и/или промените во „маркерите“ поврзани со него (на пример, грешките при компилацијата се претставени како маркери).
• Бидејќи референците за ресурси се прават преку рачката, делта природно може да упатува на далечински ресурс.

Како што наскоро ќе видиме, главните компоненти на дизајнот на механизмот за известување за промена на моделот на ресурси се релевантни и за другите модели базирани на рачка.

JDT Core

Ресурсниот модел на работниот простор Eclipse е фундаментален јазично-агностички модел. JDT Core компонентата (приклучок org.eclipse.jdt.core) обезбедува API за навигација и анализа на структурата на работниот простор од Java перспектива, т.н. „Јава модел“ (Јава модел). Овој API е дефиниран во однос на елементите на Java, за разлика од основниот модел на ресурси API, кој е дефиниран во смисла на папки и датотеки. Главните интерфејси на дрвото на елементите Java се прикажани на сл. 4.

Ориз. 4. Java Model Elements

Јава моделот ја користи истата рачка/тело идиом како и моделот на ресурси (Слика 5). IJavaElement е рачката, а JavaElementInfo ја игра улогата на телото. Интерфејсот IJavaElement дефинира протокол заеднички за сите Java елементи. Некои од неговите методи се само за рачки: getElementName(), getParent(), итн. Објектот JavaElementInfo ја складира состојбата на соодветниот елемент: неговата структура и атрибути.

Ориз. 5. IJavaElement и JavaElementInfo

Моделот Java има некои разлики во имплементацијата на основниот дизајн на рачката/телото во споредба со моделот на ресурси. Како што е наведено погоре, во моделот на ресурси, дрвото на елементите, чии јазли се објекти со информации за ресурсите, е целосно содржано во меморијата. Но, моделот Јава може да има значително поголем број елементи од дрвото на ресурсите, бидејќи ја претставува и внатрешната структура на датотеките .java и .class: типови, полиња и методи.

За да се избегне целосно материјализирање на целото стебло на елементи во меморијата, имплементацијата на моделот Java користи LRU кеш со ограничена големина на информации за елементите, каде што клучот е рачката IJavaElement. објектите со информации за елементите се креираат на барање додека се движи дрвото на елементите. Во овој случај, најмалку користените ставки се исфрлаат од кешот, а потрошувачката на меморија на моделот останува ограничена на одредената големина на кешот. Ова е уште една предност на дизајнот базиран на рачка, кој целосно ги крие таквите детали за имплементацијата од кодот на клиентот.

Механизмот за известување за промени на елементите на Java е генерално сличен на механизмот за следење на промените во ресурсите на работниот простор што беше дискутиран погоре. Клиентот кој сака да ги следи промените во моделот Java се претплати на известувања, кои се претставени како објект ElementChangedEvent кој содржи IJavaElementDelta (Слика 6).

Ориз. 6. ElementChangedEvent и IJavaElementDelta

Моделот Java не содржи информации за телата на методот или резолуцијата на имињата, така што за детална анализа на кодот напишан во Јава, JDT Core обезбедува дополнителен (не заснован на рачка) модел: апстрактно синтаксно дрво (апстрактно синтаксно дрво, AST). AST го претставува резултатот од парсирањето на изворниот текст. AST јазлите одговараат на елементите на структурата на изворниот модул (декларации, оператори, изрази итн.) и содржат информации за координатите на соодветниот елемент во изворниот текст, како и (како опција) информации за резолуцијата на името во формата на врски до т.н врзива. Врските се објекти кои претставуваат именувани ентитети, како што се типови, методи и променливи, познати на компајлерот. За разлика од AST јазлите, кои формираат дрво, сврзувањата поддржуваат вкрстени референци и генерално формираат график. Апстрактната класа ASTNode е заедничка основна класа за сите AST јазли. Подкласите на ASTNode одговараат на специфични синтаксички конструкции на јазикот Јава.

Бидејќи синтаксните дрвја можат да трошат значителна количина на меморија, JDT кешира само еден AST за активниот уредувач. За разлика од Java моделот, AST вообичаено се гледа како „среден“, „привремен“ модел чии членови не треба да ги повикуваат клиентите надвор од контекстот на операцијата што доведе до создавање на AST.

Наведените три модели (модел Java, AST, врски) заедно ја формираат основата за изградба на „интелигентни развојни алатки“ во JDT, вклучувајќи моќен Java уредник со разни „помошници“, различни активности за обработка на изворниот код (вклучувајќи организирање листа на увоз имиња и форматирање според приспособениот стил), алатки за пребарување и рефакторирање. Во овој случај, моделот Java игра посебна улога, бидејќи токму тој се користи како основа за визуелно претставување на структурата на апликацијата што се развива (на пример, во Package Explorer, Outline, Search, Call Hierarchy и Тип хиерархија).

Компоненти на Eclipse што се користат во 1C: Enterprise Developments Tools

На сл. Слика 7 ги прикажува компонентите на Eclipse кои ја формираат основата на технолошката платформа за 1C: Enterprise Development Tools.

Ориз. 7. Eclipse како платформа за 1C: Enterprise Development Tools

Платформа за затемнување обезбедува основна инфраструктура. Разгледавме некои аспекти на оваа инфраструктура во претходниот дел.

Рамка за моделирање на затемнување (Белешки) обезбедува општи средства за моделирање на структурирани податоци. EMF е интегриран со платформата Eclipse, но може да се користи посебно во редовните Java апликации. Доста често, новите програмери на Eclipse веќе се добро запознаени со EMF, иако сè уште не ги разбираат целосно сложеноста на платформата Eclipse. Една од причините за таквата заслужена популарност е универзалниот дизајн, кој вклучува, меѓу другото, унифициран API на мета-ниво, кој ви овозможува да работите со кој било EMF модел на општ начин. Основните имплементации за модели на објекти обезбедени од EMF и потсистемот за генерирање на код за модел базиран на мета-моделот значително ја зголемуваат брзината на развојот и го намалуваат бројот на грешки. EMF исто така содржи механизми за сериски модели, следење на промените на моделот и многу повеќе.

Како и секоја алатка за вистинска општа намена, ЕМП е погодна за решавање на широк опсег на проблеми со моделирање, но некои класи на модели (на пример, моделите засновани на рачка дискутирани погоре) може да бараат повеќе специјализирани алатки за моделирање. Зборувањето за ЕМП е неблагодарна задача, особено во ограничените граници на една статија, бидејќи ова е тема на посебна книга и прилично густа. Само да забележиме дека висококвалитетниот систем на генерализации во основата на EMF овозможи раѓање на цела низа проекти посветени на моделирање, кои се вклучени во проектот на највисоко ниво Моделирање на затемнување заедно со самиот ЕМП. Еден таков проект е Eclipse Xtext.

Eclipse Xtext обезбедува инфраструктура за „моделирање на текст“. Употреба на Xtext ANTLR за парсирање на изворниот текст и EMF за претставување на добиениот ASG (апстрактен семантички график, кој во суштина е комбинација од AST и врски), исто така наречен „семантички модел“. Граматиката на јазикот моделиран од Xtext е опишана на сопствениот јазик на Xtext. Ова ви овозможува не само да генерирате граматички опис за ANTLR, туку и да добиете механизам за сериска AST (т.е. Xtext обезбедува и парсер и распарсер), контекстна навестување и голем број други јазични компоненти. Од друга страна, граматичкиот јазик што се користи во Xtext е помалку флексибилен од, да речеме, граматичкиот јазик што се користи во ANTLR. Затоа, понекогаш е неопходно да се „свитка“ имплементираниот јазик на Xtext, што обично не е проблем ако зборуваме за јазик што се развива од нула, но може да биде неприфатливо за јазиците со веќе воспоставена синтакса. И покрај ова, Xtext во моментов е најзрелата, најбогата со карактеристики и разноврсна алатка во Eclipse за градење програмски јазици и развојни алатки за нив. Особено, тоа е идеална алатка за брзо создавање на прототипови јазици специфични за домен (јазик специфичен за домен, DSL). Покрај гореспоменатото „јазично јадро“ засновано на ANTLR и EMF, Xtext обезбедува многу корисни компоненти на повисоко ниво, вклучувајќи механизми за индексирање, постепена конструкција, „паметен уредник“ и многу, многу повеќе, но ја изоставува рачката- базирани јазични модели. Како и EMF, Xtext е тема достојна за посебна книга, и тешко дека можеме дури и накратко да зборуваме за сите негови способности во моментов.

1C:Enterprise Development Tools активно ги користат и самиот EMF и голем број други проекти за моделирање на Eclipse. Конкретно, Xtext е една од основите на развојните алатки за такви јазици 1C: Enterprise како што се вградениот програмски јазик и јазикот за пребарување. Друга основа за овие развојни алатки е проектот Eclipse Handly, за кој ќе разговараме подетално (од наведените компоненти на Eclipse, сè уште е најмалку познат).

Eclipse Handly, потпроект на проектот од највисоко ниво на Eclipse Technology, се појави како резултат на првичниот придонес за кодот во фондацијата Eclipse направен од 1C во 2014 година. Оттогаш, 1C продолжи да го поддржува развојот на проектот: Handly committers се вработени во компанијата. Проектот е мал, но зазема прилично уникатна ниша во Eclipse: неговата главна цел е да го поддржи развојот на модели базирани на рачка.

Основните архитектонски принципи на моделите засновани на рачка, како што е идиомот на рачка/тело, беа дискутирани погоре користејќи го моделот на ресурси и моделот Јава како примери. Исто така, забележа дека и моделот на ресурси и моделот Јава се важни основи за развојните алатки на Eclipse Java (JDT). И бидејќи скоро сите *DT Eclipse проекти имаат архитектура слична на JDT, не би било големо претерување да се каже дека моделите базирани на рачка се во основата на многу, ако не и сите IDE изградени на врвот на Eclipse платформата. На пример, Eclipse C/C++ Development Tooling (CDT) има C/C++ модел базиран на рачка кој ја игра истата улога во архитектурата CDT како и Java моделот во JDT.

Пред Handly, Eclipse не нудеше специјализирани библиотеки за градење јазични модели базирани на рачки. Моделите кои моментално постојат се создадени главно со директно прилагодување на кодот на моделот Java (ака copy/paste), во случаи кога дозволува Eclipse Public License (EPL). (Очигледно, ова обично не е правно прашање за, да речеме, самите проекти на Eclipse, но не и за производите со затворен извор.) Покрај нејзината вродена случајност, оваа техника воведува добро познати проблеми: дуплирање на кодот воведен при прилагодување на грешки, итн. Она што е полошо е што добиените модели остануваат „работи сами по себе“ и не го искористуваат потенцијалот за обединување. Но, изолирањето на заеднички концепти и протоколи за јазични модели засновани на рачки може да доведе до создавање на компоненти за повеќекратна употреба за работа со нив, слично на она што се случи во случајот со EMF.

Не е дека Eclipse не ги разбра овие прашања. Уште во 2005 година Мартин Ешлиман, сумирање на искуството од развојот на прототипот CDT, се расправаше потребата да се создаде заедничка инфраструктура за јазичните модели, вклучувајќи модели базирани на рачки. Но, како што често се случува, поради поприоритетни задачи, имплементацијата на овие идеи никогаш не стигна до неа. Во меѓувреме, факторизацијата на *DT кодот е сè уште една од недоволно развиените теми во Eclipse.

Во одредена смисла, проектот Handly е дизајниран да ги реши приближно истите проблеми како EMF, но за модели базирани на рачки, и првенствено јазични (т.е., кои претставуваат елементи на структурата на некој програмски јазик). Главните цели поставени при дизајнирање на Handly се наведени подолу:

• Идентификување на главните апстракции од предметната област.
• Намалување на напор и подобрување на квалитетот на имплементација на јазични модели базирани на рачки преку повторна употреба на код.
• Обезбедување унифициран API на мета-ниво на моделите што произлегуваат, што овозможува создавање заеднички IDE компоненти кои работат со модели базирани на јазични рачки.
• Флексибилност и приспособливост.
• Интеграција со Xtext (во посебен слој).

За да се истакнат заедничките концепти и протоколи, беа анализирани постоечките имплементации на модели базирани на јазични рачки. Главните интерфејси и основните имплементации обезбедени од Handly се прикажани на сл. 8.

Ориз. 8. Заеднички интерфејси и основни имплементации на Handly елементи

Интерфејсот IElement ја претставува рачката на елементот и е заеднички за елементите на сите модели базирани на Handly. Апстрактната класа Element го имплементира генерализираниот механизам за рачка/тело (сл. 9).

Ориз. 9. ИЕелемент и генеричка рачка/тело имплементација

Покрај тоа, Handly обезбедува генерализиран механизам за известување за промени во елементите на моделот (сл. 10). Како што можете да видите, тој е во голема мера сличен на механизмите за известување имплементирани во моделот на ресурси и моделот Јава, и користи IElementDelta за да обезбеди унифицирана репрезентација на информации за промена на елементите.

Ориз. 10. Општи интерфејси и основни имплементации на механизмот за известување Handly

Делот Handly дискутиран погоре (слика 9 и 10) може да се користи за претставување на речиси сите модели базирани на рачка. За создавање лингвистички модели, проектот нуди дополнителна функционалност - особено, заеднички интерфејси и основни имплементации за елементите на структурата на изворниот текст, т.н. изворни елементи (Сл. 8). Интерфејсот ISourceFile претставува изворна датотека, а ISourceConstruct претставува елемент во изворната датотека. Апстрактните класи SourceFile и SourceConstruct спроведуваат генерализирани механизми за поддршка на работа со изворни датотеки и нивните елементи, на пример, работа со текстуални бафери, врзување за координатите на елементот во изворниот текст, усогласување на моделите со тековната содржина на работниот бафер за копирање , итн. Спроведувањето на овие механизми обично е голем предизвик, а Handly може значително да го намали напорот за развој на јазични модели базирани на рачки преку обезбедување на висококвалитетни основни имплементации.

Покрај основните механизми наведени погоре, Handly обезбедува инфраструктура за текстуални бафери и снимки, поддршка за интеграција со уредниците на изворниот код (вклучувајќи и интеграција надвор од кутијата со Xtext уредникот), како и некои вообичаени компоненти на интерфејсот кои работа со уредувачи на изворен код.Рачни модели како што се рамка за преглед. За да ги илустрира своите способности, проектот дава неколку примери, вклучително и имплементација на Java моделот во Handly. (Во споредба со целосната имплементација на моделот Java во JDT, овој модел е намерно малку поедноставен за поголема јасност.)

Како што беше наведено претходно, главниот фокус за време на првичниот дизајн и последователниот развој на Handly беше и продолжува да биде на приспособливоста и флексибилноста.

Во принцип, моделите засновани на рачка доста добро се размеруваат „по дизајн“. На пример, идиомот за рачка/тело ви овозможува да ја ограничите количината на меморија што ја троши моделот. Но, постојат и нијанси. Така, при тестирањето на Handly за приспособливост, беше откриен проблем во имплементацијата на механизмот за известување - кога беа променети голем број елементи, конструирањето на делта траеше премногу време. Се испостави дека истиот проблем бил присутен и во моделот JDT Java, од кој еднаш бил адаптиран соодветниот код. Ја поправивме грешката во Handly и подготвивме слична лепенка за JDT, која беше примена со благодарност. Ова е само еден пример каде што воведувањето на Handly во постоечките моделски имплементации може да биде потенцијално корисно, бидејќи во овој случај таквата грешка може да се поправи на само едно место.

За да биде технички изводливо имплементирањето на Handly во постоечките модели, библиотеката мора да има значителна флексибилност. Главниот проблем е да се одржи наназад компатибилноста низ моделот API. Овој проблем беше решен во Рачно 0.5 со јасно одвојување на API специфичниот модел, дефиниран и целосно контролиран од развивачот, од унифицираниот API на мета-ниво обезбеден од библиотеката. Ова не само што го прави технички возможно имплементирањето на Handly во постоечките имплементации, туку исто така му дава значителна слобода на развивачот на новиот модел при дизајнирање на API.

Флексибилноста има и други аспекти. На пример, Handly не наметнува речиси никакви ограничувања на структурата на моделот и може да се користи за моделирање на јазици за општа намена и за специфични домен. Кога ја конструира структурата на изворната датотека, Handly не пропишува некоја посебна форма на AST претставување и, во принцип, не бара ниту присуство на самиот AST, со што се обезбедува компатибилност со речиси секој механизам за парсирање. Конечно, Handly поддржува целосна интеграција со работниот простор на Eclipse, но може да работи и директно со датотечен систем благодарение на неговата интеграција со Датотечниот систем Eclipse (EFS).

Сегашна верзија Рачно 0.6 излезе во декември 2016 година. И покрај фактот што проектот моментално е во состојба на инкубација и API сè уште не е конечно фиксиран, Handly веќе се користи во два големи комерцијални производи кои го презедоа ризикот да дејствуваат како „рани усвоени“ и, морам да кажам, уште не жали.

Како што е наведено погоре, еден од овие производи е 1C: Enterprise Development Tools, каде што Handly се користи од самиот почеток за моделирање елементи на структурата на високо ниво на таквите јазици 1C: Enterprise како вграден програмски јазик и јазик за пребарување. . Друг производ е помалку познат на пошироката јавност. Ова Студио Кодасип, интегрирано дизајнерско опкружување за процесор за сет на инструкции специфичен за апликација (ASIP), што се користи и во самата чешка компанија Codasip и од нејзините клиенти, вклучително и AMD, AVG, Мобилеј, Дизајни на Сигма. Codasip го користи Handly во производство од 2015 година, почнувајќи со верзијата Handly 0.2. Најновото издание на Codasip Studio ја користи верзијата 0.5, објавена во јуни 2016 година. Онджеј Илчик, кој го предводи развојот на IDE во Codasip, е во контакт со проектот, обезбедувајќи витални повратни информации во име на „третата страна усвоител“. Тој дури можеше да најде слободно време за директно да учествува во развојот на проектот, имплементирајќи UI слој (~ 4000 линии код) за еден од примерите на Handly, модел на Java. Подетални информации од прва рака за употребата на Handly од страна на посвоителите може да се најдат на страницата Успешни приказни проект.

Се надеваме дека по објавувањето на верзијата 1.0 со гаранција за стабилност на API и проектот напуштање на состојбата на инкубација, Handly ќе има нови усвоители. Во меѓувреме, проектот продолжува да го тестира и дополнително го подобрува API, објавувајќи две „главни“ изданија годишно - во јуни (ист датум како и истовременото објавување на Eclipse) и декември, обезбедувајќи предвидлив распоред на кој можат да се потпрат усвоителите. Можеме да додадеме и дека „стапката на грешки“ на проектот останува на постојано ниско ниво и Handly работи сигурно во производите на раните усвоени уште од првите верзии. За понатамошно истражување на Eclipse Handly, можете да користите Упатство за почеток и Архитектонски преглед.

Извор: www.habr.com