Verŝajne, delonge ne bezonas specialan enkondukon. Multaj homoj konas Eclipse danke al la evoluiloj de Eclipse Java (). Estas ĉi tiu populara malfermfonta Java IDE, kiun plej multaj programistoj asocias kun la vorto "Eklipso". Tamen, Eclipse estas kaj etendebla platformo por integri evoluilojn (Eclipse Platform), kaj kelkaj IDEoj konstruitaj sur ĝia bazo, inkluzive de JDT. Eclipse estas kaj la Eclipse Project, la altnivela projekto kiu kunordigas la evoluon de la Eclipse Platform kaj la JDT, kaj la Eclipse SDK, la liverita rezulto de tiu evoluo. Fine, Eclipse estas malfermfonta Fondaĵo kun grandega komunumo de projektoj, kiuj ne ĉiuj estas skribitaj en Java aŭ rilataj al evoluiloj (ekzemple projektoj). и ). La mondo de Eclipse estas tre diversa.
En ĉi tiu artikolo, kiu estas superrigardo en naturo, ni provos rigardi kelkajn el la bazaĵoj de la Eclipse-arkitekturo kiel platformo por konstrui integrajn evoluilojn kaj doni komencan ideon pri la Eclipse-komponentoj, kiuj formas la fundamenton de la teknologio. platformo por la "nova Konfiguranto" 1C: Enterprise. . Kompreneble, tia recenzo neeviteble estos plejparte supraĵa kaj sufiĉe limigita, inkluzive ĉar ni fokusiĝas ne nur al Eclipse-programistoj kiel la celgrupo. Tamen ni esperas, ke eĉ spertaj programistoj de Eclipse povos trovi interesajn informojn en la artikolo. Ekzemple, ni parolos pri unu el la "sekretoj de Eklipso", relative nova kaj malmulte konata projekto. , kiu estis fondita kaj subtenita de 1C.
Enkonduko al Eclipse Architecture
Ni unue rigardu kelkajn ĝeneralajn aspektojn de la Eclipse-arkitekturo uzante la ekzemplon (JDT). La elekto de JDT kiel ekzemplo ne estas hazarda. Ĉi tiu estas la unua integra evolumedio aperanta en Eclipse. Aliaj *DT Eclipse-projektoj, kiel ekzemple Eclipse C/C++ Development Tooling (CDT), estis kreitaj poste kaj pruntas kaj bazajn arkitekturajn principojn kaj individuajn fontkodfragmentojn de JDT. La fundamentoj de la arkitekturo fiksitaj en JDT estas gravaj ĝis hodiaŭ por preskaŭ ajna IDE konstruita sur la Eclipse Platformo, inkluzive de 1C:Enterprise Development Tools.
Antaŭ ĉio, oni devas rimarki, ke Eklipso estas karakterizita per sufiĉe klara arkitektura tavoliĝo, kun la apartigo de lingvo-sendependa funkcieco de funkcieco dizajnita por subteni specifajn programlingvojn, kaj la apartigo de UI-sendependaj "kernaj" komponentoj de komponentoj asociitaj. kun subtena uzantinterfaco.
Tiel, la Eclipse Platformo difinas komunan, lingvosendependan infrastrukturon, kaj la Java evoluiloj aldonas plenefikan Java IDE al Eclipse. Kaj la Eclipse Platform kaj la JDT konsistas el pluraj komponentoj, ĉiu el kiuj apartenas aŭ al UI-sendependa "kerno" aŭ UI-tavolo (Figuro 1).
Rizo. 1. Eclipse Platform kaj JDT
Ni listigu la ĉefajn komponantojn de la Eclipse Platform:
- Rultempa tempo — Difinas la krominfrastrukturon. Eklipso estas karakterizita per modula arkitekturo. Esence, Eclipse estas kolekto de "etendpunktoj" kaj "etendaĵoj".
- Laborspaco — Administras unu aŭ plurajn projektojn. Projekto konsistas el dosierujoj kaj dosieroj, kiuj estas mapitaj rekte al la dosiersistemo.
- Norma Fenestraĵa Ilaro (SWT) - Provizas bazajn uzantinterfacajn elementojn integritajn kun la operaciumo.
- JVizaĝo — Provizas kelkajn UI-kadrojn konstruitajn sur SWT.
- Laboro — Difinas la paradigmon de Eclipse UI: redaktiloj, vidoj, perspektivoj.
Oni devas diri, ke la Eklipso-Platformo ankaŭ provizas multajn aliajn utilajn komponantojn por konstrui integrajn evoluilojn, inkluzive Sencimigi, Komparu, Serĉi kaj Teamon. Speciala mencio estu JFace Text - la bazo por konstrui "inteligentajn redaktilojn" de fontkodo. Bedaŭrinde, eĉ mallonga ekzameno de ĉi tiuj komponantoj, same kiel la UI-tavolaj komponantoj, ne eblas en la medio de ĉi tiu artikolo, do en la resto de ĉi tiu sekcio ni limigos nin al superrigardo de la ĉefaj "kernaj" komponantoj de la Eklipso-Platformo kaj JDT.
Kerna Rultempo
La Eclipse krominfrastrukturo estas bazita sur kaj provizita de la projekto . Ĉiu Eclipse kromaĵo estas OSGi-pakaĵo. La OSGi-specifo difinas, aparte, mekanismojn por versionado kaj dependecrezolucio. Aldone al tiuj normaj mekanismoj, Ekvinokso lanĉas la koncepton ekspansiopunktoj. Ĉiu kromaĵo povas difini siajn proprajn etendpunktojn, kaj ankaŭ enkonduki pliajn funkciojn ("etendaĵojn") al la sistemo uzante etendpunktojn difinitajn de la sama aŭ aliaj aldonaĵoj. Ĉiu detala priskribo de la mekanismoj OSGi kaj Equinox estas preter la amplekso de ĉi tiu artikolo. Ni nur rimarku, ke moduligo en Eclipse estas totala (ĉiu ajn subsistemo, inkluzive de Runtime, konsistas el unu aŭ pluraj kromprogramoj), kaj preskaŭ ĉio en Eclipse estas etendaĵo. Krome, tiuj principoj estis enkonstruitaj en la Eclipse-arkitekturo long antaŭ la enkonduko de OSGi (en tiu tempo ili uzis sian propran teknologion, multe similan al OSGi).
Kerna Laborspaco
Preskaŭ ĉiu integra evolumedio konstruita sur la Eclipse Platformo funkcias kun Eclipse laborspaco. Ĝi estas la laborspaco kiu kutime enhavas la fontkodon de la aplikaĵo disvolvita en la IDE. Laborspaco mapas rekte al la dosiersistemo kaj konsistas el projektoj, kiuj enhavas dosierujojn kaj dosierojn. Ĉi tiuj projektoj, dosierujoj kaj dosieroj estas nomitaj rimedoj laborspaco. La realigo de laborspaco en Eclipse funkcias kiel kaŝmemoro rilate al la dosiersistemo, kio ebligas signife akceli traveturadon de la rimedarbo. Krome, laborspaco disponigas kelkajn kromajn servojn, inkluzive de и .
La komponanto Core Resources (kromaĵo org.eclipse.core.resources) respondecas pri subteni la laborspacon kaj ĝiajn rimedojn. Aparte, ĉi tiu komponanto provizas programan aliron al la laborspaco en la formo modeloj de rimedoj. Por labori efike kun ĉi tiu modelo, klientoj bezonas simplan manieron prezenti ligon al rimedo. En ĉi tiu kazo, estus dezirinde kaŝi la objekton, kiu rekte stokas la staton de la rimedo en la modelo de klienta aliro. Alie, en la kazo de, ekzemple, forigo de dosiero, la kliento povus daŭre teni objekton, kiu ne plu estas en la modelo, kun la sekvaj problemoj. Eklipso solvas ĉi tiun problemon uzante ion nomatan pritrakti rimedo. Tenilo funkcias kiel ŝlosilo (ĝi nur konas la vojon al la rimedo en la laborspaco) kaj tute kontrolas aliron al la interna modelobjekto, kiu rekte stokas informojn pri la stato de la rimedo. Ĉi tiu dezajno estas vario de la ŝablono .
Rizo. Figuro 2 ilustras la Tenilo/Korpo-idiomon kiel aplikatan al la rimedmodelo. La IResource-interfaco reprezentas la tenilon de rimedo kaj estas API, male al la Resource-klaso, kiu efektivigas ĉi tiun interfacon, kaj la ResourceInfo-klaso, kiu reprezentas la korpon, kiuj ne estas APIoj. Ni emfazas, ke tenilo nur konas la vojon al la rimedo relative al la laborspaca radiko kaj ne enhavas ligilon al rimeda informo. Rimedaj informoj-objektoj formas tiel nomatan "elementarbon". Ĉi tiu datumstrukturo estas tute realigita en memoro. Por trovi la rimedan informon okazon respondan al tenilo, la elementarbo estas traigata laŭ la vojo konservita en tiu tenilo.
Rizo. 2. IResource kaj ResourceInfo
Kiel ni vidos poste, la baza dezajno de la rimeda modelo (ni povus nomi ĝin tenilo-bazita) estas uzata en Eclipse ankaŭ por aliaj modeloj. Nuntempe, ni listigu kelkajn el la karakterizaj propraĵoj de ĉi tiu dezajno:
- Tenilo estas valorobjekto. Valorobjektoj estas neŝanĝeblaj objektoj, kies egaleco ne baziĝas sur identeco. Tiaj objektoj povas esti sekure uzataj kiel ŝlosilo en hakitaj ujoj. Multoblaj okazoj de tenilo povas referenci la saman rimedon. Por kompari ilin, vi devas uzi la metodon equals(Object).
- Tenilo difinas la konduton de rimedo, sed ne enhavas informojn pri la stato de la rimedo (la nuraj datumoj kiujn ĝi stokas estas la "ŝlosilo", la vojo al la rimedo).
- Tenilo povas rilati al rimedo kiu ne ekzistas (aŭ rimedo kiu ankoraŭ ne estis kreita, aŭ rimedo kiu jam estis forigita). La ekzisto de rimedo povas esti kontrolita per la metodo IResource.exists().
- Kelkaj operacioj povas esti efektivigitaj surbaze sole de informoj stokitaj en la tenilo mem (tielnomitaj tenilo-restriktitaj operacioj). Ekzemploj estas IResource.getParent(), getFullPath(), ktp. La rimedo ne bezonas ekzisti por ke tia operacio sukcesu. Operacioj, kiuj postulas ke rimedo ekzistu por sukcesi, ĵetas CoreException se la rimedo ne ekzistas.
Eklipso provizas efikan mekanismon por sciigi ŝanĝojn pri laborspacaj rimedoj (Figuro 3). Rimedoj povas ŝanĝiĝi aŭ kiel rezulto de agoj faritaj ene de la Eclipse IDE mem aŭ kiel rezulto de sinkronigo kun la dosiersistemo. En ambaŭ kazoj, klientoj, kiuj abonas sciigojn, ricevas detalajn informojn pri la ŝanĝoj en formo de "rimedodeltoj". Delto priskribas ŝanĝojn inter du statoj de laborspaca rimedo (sub-)arbo kaj estas mem arbo, ĉiu nodo de kiu priskribas ŝanĝon al rimedo kaj enhavas liston de deltoj ĉe la sekva nivelo kiuj priskribas ŝanĝojn al infanresursoj.
Rizo. 3. IResourceChangeEvent kaj IResourceDelta
La sciiga mekanismo bazita sur rimeddeltoj havas la sekvajn karakterizaĵojn:
- Ununura ŝanĝo kaj multaj ŝanĝoj estas priskribitaj uzante la saman strukturon, ĉar la delto estas konstruita uzante la principon de rekursiva kunmetaĵo. Abonantaj klientoj povas prilabori sciigojn pri ŝanĝaj rimedoj uzante rekursivan devenon tra arbo de deltoj.
- La delto enhavas kompletajn informojn pri ŝanĝoj al la rimedo, inkluzive de ĝia movado kaj/aŭ ŝanĝoj en la "markoj" asociitaj kun ĝi (ekzemple, kompilaj eraroj estas reprezentitaj kiel markiloj).
- Ĉar rimedreferencoj estas faritaj per la tenilo, delta povas nature referenci malproksiman rimedon.
Kiel ni baldaŭ vidos, la ĉefaj komponantoj de la dezajno de la rimeda modelo-ŝanĝa sciiga mekanismo estas ankaŭ gravaj por aliaj teniloj bazitaj en modeloj.
JDT Kerno
La Eclipse laborspaca rimedmodelo estas fundamenta lingvo-agnostika modelo. La JDT Core-komponento (kromaĵo org.eclipse.jdt.core) disponigas API por navigi kaj analizi la laborspacan strukturon de Java perspektivo, la tielnomita "Java modelo" (Java modelo). Ĉi tiu API estas difinita laŭ Java elementoj, kontraste al la subesta rimeda modelo API, kiu estas difinita laŭ dosierujoj kaj dosieroj. La ĉefaj interfacoj de la Java-elementarbo estas montritaj en Fig. 4.
Rizo. 4. Java Modelaj Elementoj
La Java-modelo uzas la saman tenilon/korpan idiomon kiel la rimedmodelo (Figuro 5). IJavaElement estas la tenilo, kaj JavaElementInfo ludas la rolon de korpo. La interfaco IJavaElement difinas protokolon komunan al ĉiuj Java-elementoj. Kelkaj el ĝiaj metodoj estas nur por tenilo: getElementName(), getParent(), ktp. La JavaElementInfo objekto konservas la staton de la responda elemento: ĝia strukturo kaj atributoj.
Rizo. 5. IJavaElement kaj JavaElementInfo
La Java modelo havas kelkajn diferencojn en la efektivigo de la baza tenilo/korpdezajno komparite kun la rimedmodelo. Kiel notite supre, en la rimedmodelo, la elementarbo, kies nodoj estas rimedinformobjektoj, estas tute enhavita en memoro. Sed la Java modelo povas havi signife pli grandan nombron da elementoj ol la rimedarbo, ĉar ĝi ankaŭ reprezentas la internan strukturon de .java kaj .class dosieroj: tipoj, kampoj kaj metodoj.
Por eviti tute konkretigi la tutan arbon de elementoj en memoro, la Java modelefektivigo uzas limigitan grandecon LRU-kaŝmemoro de elemento-informoj, kie la ŝlosilo estas tenilo IJavaElement. elemento-informobjektoj estas kreitaj laŭpeto dum la elemento-arbo estas navigita. En ĉi tiu kazo, la malplej ofte uzataj eroj estas forigitaj de la kaŝmemoro, kaj la memorkonsumo de la modelo restas limigita al la specifita kaŝmemorgrandeco. Ĉi tio estas alia avantaĝo de tenilo-bazita dezajno, kiu tute kaŝas tiajn efektivigajn detalojn de la klientokodo.
La mekanismo por sciigi ŝanĝojn al Java elementoj estas ĝenerale simila al la mekanismo por spuri ŝanĝojn al laborspacaj rimedoj diskutitaj supre. Kliento deziranta monitori ŝanĝojn en la Java modelo abonas sciigojn, kiuj estas reprezentitaj kiel ElementChangedEvent-objekto kiu enhavas IJavaElementDelta (Figuro 6).
Rizo. 6. ElementChangedEvent kaj IJavaElementDelta
La Java-modelo ne enhavas informojn pri metodokorpoj aŭ nomrezolucio, do por detala analizo de kodo skribita en Java, JDT Core disponigas kroman (ne-tenil-bazitan) modelon: (abstrakta sintaksa arbo, AST). AST reprezentas la rezulton de analizado de la fontteksto. AST-nodoj respondas al elementoj de la strukturo de la fontmodulo (deklaroj, operatoroj, esprimoj, ktp.) kaj enhavas informojn pri la koordinatoj de la responda elemento en la fontteksto, same kiel (kiel opcio) informojn pri nomrezolucio en la formo de ligiloj al tn ligiloj. Ligiloj estas objektoj kiuj reprezentas nomitajn unuojn, kiel ekzemple tipoj, metodoj kaj variabloj, konataj al la kompililo. Male al AST-nodoj, kiuj formas arbon, ligiloj apogas krucreferencojn kaj ĝenerale formas grafeon. La abstrakta klaso ASTNode estas la komuna bazklaso por ĉiuj AST-nodoj. ASTNode-subklasoj egalrilatas al specifaj sintaksaj konstrukcioj de la Java lingvo.
Ĉar sintaksoarboj povas konsumi signifan kvanton da memoro, JDT konservas nur unu AST por la aktiva redaktilo. Male al la Java modelo, la AST estas tipe rigardita kiel "meza", "provizora" modelo, al kies elementoj klientoj ne devus teni referencojn ekster la kunteksto de la operacio kiu kaŭzis la kreadon de la AST.
La listigitaj tri modeloj (Java modelo, AST, ligadoj) kune formas la bazon por konstrui "inteligentajn evoluilojn" en JDT, inkluzive de potenca Java redaktilo kun diversaj "helpantoj", diversaj agoj por prilaborado de fontkodo (inkluzive de organizado de listo de importado). nomoj kaj formatado laŭ la personigita stilo), serĉo kaj refactoring iloj. En ĉi tiu kazo, la Java-modelo ludas specialan rolon, ĉar ĝi estas kiu estas uzata kiel bazo por vida reprezentado de la strukturo de la evoluiga aplikaĵo (ekzemple en Package Explorer, Outline, Search, Call Hierarchy, kaj Tipo Hierarkio).
Eclipse-komponentoj uzataj en 1C:Enterprise Developments Tools
En Fig. Figuro 7 montras la Eclipse-komponentojn, kiuj formas la fundamenton de la teknologia platformo por 1C:Enterprise Development Tools.
Rizo. 7. Eklipso kiel platformo por 1C:Enterprise Development Tools
Eklipso Platformo provizas bazan infrastrukturon. Ni rigardis kelkajn aspektojn de ĉi tiu infrastrukturo en la antaŭa sekcio.
(EMF) disponigas ĝeneralan rimedon de modeligado de strukturitaj datenoj. EMF estas integrita kun la Eclipse Platformo, sed ankaŭ povas esti uzata aparte en regulaj Java-aplikoj. Sufiĉe ofte, novaj Eclipse-programistoj jam bone konas EMF, kvankam ili ankoraŭ ne plene komprenas la komplikaĵojn de la Eclipse Platformo. Unu el la kialoj de tia meritita populareco estas la universala dezajno, kiu inkluzivas interalie unuigitan meta-nivelan API, kiu ebligas al vi labori kun ajna EMF-modelo en ĝenerala maniero. La bazaj efektivigoj por modelobjektoj disponigitaj fare de EMF kaj la subsistemo por generado de modelkodo bazita sur la meta-modelo signife pliigas la rapidecon de evoluo kaj reduktas la nombron da eraroj. EMF ankaŭ enhavas mekanismojn por seriigi modelojn, spuri ŝanĝojn al la modelo, kaj multe pli.
Kiel ĉiu vere ĝeneraluzebla ilo, EMF taŭgas por solvi larĝan gamon de modeligaj problemoj, sed kelkaj klasoj de modeloj (ekzemple, la tenil-bazitaj modeloj diskutitaj supre) povas postuli pli specialecajn modelilojn. Paroli pri EMF estas sendanka tasko, precipe en la limigitaj limoj de unu artikolo, ĉar tio estas temo de aparta libro, kaj sufiĉe dika. Ni nur rimarku, ke la altkvalita sistemo de ĝeneraligoj sub la EMF permesis la naskiĝon de tuta gamo da projektoj dediĉitaj al modeligado, kiuj estas inkluzivitaj en la altnivela projekto. kune kun la EMF mem. Unu tia projekto estas Eclipse Xtext.
disponigas infrastrukturon de "tekstomodelado". Xtext uzas por analizado de la fontoteksto kaj EMF por reprezentado de la rezulta ASG (abstrakta semantika grafeo, kiu estas esence kombinaĵo de AST kaj ligadoj), ankaŭ nomita la "semantika modelo". La gramatiko de la lingvo modeligita de Xtext estas priskribita en la propra lingvo de Xtext. Ĉi tio ebligas al vi ne nur generi gramatikan priskribon por ANTLR, sed ankaŭ akiri AST-serialigmekanismon (t.e. Xtext provizas kaj analizilon kaj malanalizan), kuntekstan sugeston kaj kelkajn aliajn lingvokomponentojn. Aliflanke, la gramatika lingvo uzata en Xtext estas malpli fleksebla ol, ekzemple, la gramatika lingvo uzata en ANTLR. Tial, foje necesas "fleksi" la efektivigitan lingvon al Xtext, kio kutime ne estas problemo se ni parolas pri lingvo disvolvita de nulo, sed povas esti neakceptebla por lingvoj kun jam establita sintakso. Malgraŭ tio, Xtext estas nuntempe la plej matura, riĉa kaj multflanka ilo en Eclipse por konstrui programlingvojn kaj evoluilojn por ili. Aparte, ĝi estas ideala ilo por rapida prototipado (domajna specifa lingvo, DSL). Krom la supre menciita "lingva kerno" bazita sur ANTLR kaj EMF, Xtext provizas multajn utilajn pli altnivelajn komponentojn, inkluzive de indeksaj mekanismoj, pliiga konstruo, "inteligenta redaktilo", kaj multe, multe pli, sed forlasas tenilon. bazitaj lingvomodeloj. Kiel EMF, Xtext estas temo inda je aparta libro, kaj ni apenaŭ povas eĉ mallonge paroli pri ĉiuj ĝiaj kapabloj nun.
1C:Enterprise Development Tools aktive uzas kaj EMF mem kaj kelkajn aliajn Eclipse Modeling-projektojn. Precipe, Xtext estas unu el la fundamentoj de evoluiloj por tiaj 1C:Enterprise-lingvoj kiel la enkonstruita programlingvo kaj demandlingvo. Alia bazo por ĉi tiuj evoluiloj estas la projekto Eclipse Handly, pri kiu ni diskutos pli detale (el la listigitaj komponantoj de Eclipse, ĝi ankoraŭ estas la malplej konata).
, subprojekto de la Eclipse Technology-pintnivela projekto, aperis kiel rezulto de komenca kodkontribuo al la Eclipse Foundation farita fare de 1C en 2014. Ekde tiam, 1C daŭre subtenis la evoluon de la projekto: Handly committers estas dungitoj de la firmao. La projekto estas malgranda, sed ĝi okupas sufiĉe unikan niĉon en Eclipse: ĝia ĉefa celo estas subteni la disvolviĝon de tenilo-bazitaj modeloj.
La bazaj arkitekturaj principoj de tenil-bazitaj modeloj, kiel ekzemple la tenilo/korpidiomo, estis diskutitaj supre utiligante la rimedmodelon kaj la Java modelon kiel ekzemplojn. Ĝi ankaŭ notis ke kaj la rimedmodelo kaj la Java modelo estas gravaj fundamentoj por la Eclipse Java evoluiloj (JDT). Kaj ĉar preskaŭ ĉiuj *DT Eclipse-projektoj havas arkitekturon similan al JDT, ne estus granda troigo diri, ke tenilo-bazitaj modeloj subestas multaj, se ne ĉiuj IDEoj konstruitaj sur la Eclipse Platformo. Ekzemple, la Eclipse C/C++ Development Tooling (CDT) havas tenil-bazitan C/C++ modelon kiu ludas la saman rolon en la CDT-arkitekturo kiel la Java modelo faras en la JDT.
Antaŭ Handly, Eclipse ne ofertis specialecajn bibliotekojn por konstrui tenil-bazitajn lingvomodelojn. La modeloj kiuj ekzistas nuntempe estis kreitaj ĉefe per rekte adaptado de la Java modelkodo (alinome kopii/glui), en kazoj kie ĝi permesas Eclipse Public License (EPL). (Evidente, ĉi tio kutime ne estas laŭleĝa afero por, ekzemple, Eclipse-projektoj mem, sed ne por fermitfontaj produktoj.) Krom sia propra hazardo, tiu tekniko enkondukas konatajn problemojn: kodduobligo enkondukita de kiam adaptado al eraroj, ktp. Plej malbona estas, ke la rezultaj modeloj restas "aĵoj en si mem" kaj ne utiligas la potencialon por unuigo. Sed izoli komunajn konceptojn kaj protokolojn por tenilo-bazitaj lingvomodeloj povus konduki al la kreado de reuzeblaj komponantoj por labori kun ili, simile al kio okazis en la kazo de EMF.
Ne estas ke Eclipse ne komprenis ĉi tiujn aferojn. Reen en 2005 , resumante la sperton de evoluigado de la CDT-prototipo, la bezono krei komunan infrastrukturon por lingvomodeloj, inkluzive de tenilo-bazitaj modeloj. Sed, kiel ofte okazas, pro pli altaj prioritataj taskoj, la efektivigo de ĉi tiuj ideoj neniam atingis ĝin. Dume, faktorigo de *DT-kodo daŭre estas unu el la subevoluintaj temoj en Eclipse.
En certa signifo, la Handly-projekto estas dizajnita por solvi proksimume la samajn problemojn kiel EMF, sed por tenilo-bazitaj modeloj, kaj ĉefe lingvaj (t.e., reprezentantaj elementojn de la strukturo de iu programlingvo). La ĉefaj celoj fiksitaj dum desegnado de Handly estas listigitaj malsupre:
- Identigo de la ĉefaj abstraktaĵoj de la temo.
- Reduktante fortostreĉon kaj plibonigante la kvaliton de efektivigo de tenilo-bazitaj lingvomodeloj per koda reuzo.
- Disponigante unuigitan meta-nivelan API al la rezultaj modeloj, ebligante krei komunajn IDE-komponentojn kiuj funkcias kun lingvotenil-bazitaj modeloj.
- Fleksebleco kaj skaleblo.
- Integriĝo kun Xtext (en aparta tavolo).
Por elstarigi oftajn konceptojn kaj protokolojn, ekzistantaj efektivigoj de lingvotenil-bazitaj modeloj estis analizitaj. La ĉefaj interfacoj kaj bazaj efektivigoj disponigitaj fare de Handly estas montritaj en Fig. 8.
Rizo. 8. Komunaj interfacoj kaj bazaj efektivigoj de Handly-elementoj
La IElement-interfaco reprezentas la tenilon de elemento kaj estas komuna al elementoj de ĉiuj Handly-bazitaj modeloj. La abstrakta klaso Elemento efektivigas la ĝeneraligitan tenilon/korpan mekanismon (Fig. 9).
Rizo. 9. IElement kaj ĝenerala tenilo/korpa efektivigo
Krome, Handly disponigas ĝeneraligitan mekanismon por sciigi pri ŝanĝoj en modelelementoj (Fig. 10). Kiel vi povas vidi, ĝi estas larĝe simila al la sciigaj mekanismoj efektivigitaj en la rimeda modelo kaj la Java modelo, kaj uzas IElementDelta por provizi unuigitan reprezentadon de elementŝanĝaj informoj.
Rizo. 10. Ĝeneralaj interfacoj kaj bazaj efektivigoj de la Handly sciiga mekanismo
La Handly-parto diskutita supre (Fig. 9 kaj 10) povas esti uzata por reprezenti preskaŭ iujn ajn tenil-bazitajn modelojn. Por krei lingvaj modeloj, la projekto ofertas aldonan funkciecon - precipe komunajn interfacojn kaj bazajn realigojn por elementoj de la fonttekstostrukturo, la t.n. fontelementoj (Fig. 8). La ISourceFile-interfaco reprezentas fontdosieron, kaj ISourceConstruct reprezentas elementon ene de la fontdosiero. La abstraktaj klasoj SourceFile kaj SourceConstruct efektivigas ĝeneraligitajn mekanismojn por subteni laboradon kun fontdosieroj kaj iliaj elementoj, ekzemple, laborado kun tekstbufroj, ligado al la koordinatoj de elemento en la fontteksto, akordigi modelojn kun la nuna enhavo de funkcia kopia bufro. , ktp. Efektivigi ĉi tiujn mekanismojn estas kutime sufiĉe defio, kaj Handly povas signife redukti la fortostreĉon evoluigi tenil-bazitajn lingvomodelojn disponigante altkvalitajn bazajn efektivigojn.
Aldone al la kernaj mekanismoj listigitaj supre, Handly disponigas infrastrukturon por tekstaj bufroj kaj momentfotoj, subtenon por integriĝo kun fontkodredaktiloj (inkluzive de senfina integriĝo kun la Xtext-redaktilo), same kiel kelkajn komunajn UI-komponentojn kiuj labori kun fontkodaj redaktiloj.Maneblaj modeloj kiel skiza kadro. Por ilustri ĝiajn kapablojn, la projekto disponigas plurajn ekzemplojn, inkluzive de efektivigo de la Java modelo en Handly. (Kompare kun la plena efektivigo de la Java modelo en JDT, ĉi tiu modelo estas intencite iom simpligita por pli granda klareco. )
Kiel notite pli frue, grava fokuso dum la komenca dezajno kaj posta evoluo de Handly estis kaj daŭre estas sur skaleblo kaj fleksebleco.
Principe, tenilo-bazitaj modeloj skalas sufiĉe bone "laŭ dezajno". Ekzemple, la tenilo/korpa idiomaĵo permesas vin limigi la kvanton de memoro konsumita de modelo. Sed estas ankaŭ nuancoj. Tiel, dum testado de Handly pri skaleblo, problemo estis malkovrita en la efektivigo de la sciiga mekanismo - kiam granda nombro da elementoj estis ŝanĝitaj, konstrui deltojn prenis tro da tempo. Montriĝis, ke la sama problemo ĉeestis en la JDT Java modelo, el kiu la responda kodo iam estis adaptita. Ni riparis la cimon en Handly kaj preparis similan flikilon por JDT, kiu estis dankeme ricevita. Ĉi tio estas nur unu ekzemplo kie enkonduki Handly en ekzistantajn modelefektivigojn povus esti eble utila, ĉar ĉi-kaze tia cimo povus esti riparita en nur unu loko.
Por igi efektivigi Handly en ekzistantajn modelefektivigojn teknike realigebla, la biblioteko devas havi signifan flekseblecon. La ĉefa problemo estas konservi malantaŭan kongruon tra la API-modelo. Ĉi tiu problemo estis solvita en klare apartigante la modelo-specifan API, difinitan kaj plene kontrolitan de la programisto, de la unuigita meta-nivela API provizita de la biblioteko. Ĉi tio ne nur ebligas teknike efektivigi Handly en ekzistantajn efektivigojn, sed ankaŭ donas al la nova modelprogramisto signifan liberecon dum desegnado de la API.
Fleksebleco ankaŭ havas aliajn aspektojn. Ekzemple, Handly trudas preskaŭ neniujn restriktojn sur la strukturo de la modelo kaj povas esti uzita por modeligi kaj ĝeneraluzeblajn kaj domajn-specifajn lingvojn. Konstruante la strukturon de la fontdosiero, Handly ne preskribas ajnan apartan formon de AST-reprezento kaj, principe, eĉ ne postulas la ĉeeston de AST mem, tiel certigante kongruon kun preskaŭ ajna analiza mekanismo. Fine, Handly subtenas plenan integriĝon kun Eclipse laborspaco, sed ankaŭ povas funkcii rekte kun dosiersistemoj danke al sia integriĝo kun (EFS).
Nuna versio aperis en decembro 2016. Malgraŭ la fakto, ke la projekto estas nuntempe en stato de kovado kaj la API ankoraŭ ne estis finfine riparita, Handly jam estas uzata en du grandaj komercaj produktoj, kiuj riskis agi kiel "fruaj adoptantoj", kaj, mi devas diri, ne bedaŭras ĝin ankoraŭ.
Kiel notite supre, unu el ĉi tiuj produktoj estas 1C:Enterprise Development Tools, kie Handly estas uzata de la komenco por modeligi elementojn de la altnivela strukturo de tiaj 1C:Enterprise-lingvoj kiel la enkonstruita programlingvo kaj demandlingvo. . Alia produkto estas malpli konata de la ĝenerala publiko. Ĉi tio , integra dezajnmedio por aplikaĵ-specifa instrukci-ara procesoro (ASIP), uzita kaj ene de la ĉeĥa firmao Codasip mem kaj de ĝiaj klientoj, inkluzive de , , , . Codasip uzas Handly en produktado ekde 2015, komencante kun versio Handly 0.2. La plej nova eldono de Codasip Studio uzas version 0.5, publikigitan en junio 2016. Ondřej Ilčík, kiu gvidas IDE-disvolviĝon ĉe Codasip, estas en kontakto kun la projekto, liverante esencajn rimarkojn nome de la "tria partia adoptanto". Li eĉ povis trovi iom da libera tempo por rekte partopreni en la evoluo de la projekto, efektivigante UI-tavolon (~4000 linioj de kodo) por unu el la Handly-ekzemploj, Java-modelo. Pli detalaj unuamanaj informoj pri la uzo de Handly de adoptantoj troveblas sur la paĝo projekto.
Ni esperas, ke post la liberigo de versio 1.0 kun garantio de API-stabileco kaj la projekto forlasanta la inkubacion, Handly havos novajn adoptantojn. Intertempe, la projekto daŭre testas kaj plu plibonigas la API, publikigante du "gravajn" eldonojn jare - en junio (la sama dato kiel la samtempa eldono de Eclipse) kaj decembro, provizante antaŭvideblan horaron, je kiu adoptantoj povas fidi. Ni ankaŭ povas aldoni, ke la "cimoprocento" de la projekto restas sur konstante malalta nivelo kaj Handly laboras fidinde en la produktoj de fruaj adoptantoj ekde la unuaj versioj. Por plu esplori Eclipse Handly, vi povas uzi и .
fonto: www.habr.com