Forse, ùn hà micca bisognu di una presentazione speciale. Parechje persone sò familiarizati cù Eclipse grazia à l'arnesi di sviluppu Eclipse Java (). Hè stu populari Java IDE open-source chì a maiò parte di i sviluppatori assucianu cù a parolla "Eclipse". Tuttavia, Eclipse hè sia una piattaforma estensibile per l'integrazione di strumenti di sviluppu (Eclipse Platform), è una quantità di IDE custruiti nantu à a so basa, cumpresu JDT. Eclipse hè à tempu u Prughjettu Eclipse, u prughjettu di primu livellu chì coordina u sviluppu di a Piattaforma Eclipse è u JDT, è l'Eclipse SDK, u risultatu furnitu di quellu sviluppu. Infine, Eclipse hè una Fundazione open-source cù una grande cumunità di prughjetti, micca tutti scritti in Java o in relazione cù strumenti di sviluppu (per esempiu, prughjetti). и ). U mondu di Eclipse hè assai diversu.
In questu articulu, chì hè una panoramica in natura, pruveremu à guardà alcune di e basi di l'architettura Eclipse cum'è una piattaforma per custruisce strumenti di sviluppu integrati è dà una idea iniziale di i cumpunenti Eclipse chì formanu u fundamentu di a tecnulugia. piattaforma per u "novu Configuratore" 1C: Enterprise. . Di sicuru, una tale rivista serà inevitabbilmente largamente superficiale è piuttostu limitata, ancu perchè ci focalizemu micca solu nantu à i sviluppatori di Eclipse cum'è u publicu di destinazione. Tuttavia, speremu chì ancu i sviluppatori Eclipse sperimentati puderanu truvà infurmazioni interessanti in l'articulu. Per esempiu, parlemu di unu di i "sicreti di Eclipse", un prughjettu relativamente novu è pocu cunnisciutu. , chì hè stata fundata è sustinuta da 1C.
Introduzione à l'architettura Eclipse
Fighjemu prima alcuni aspetti generali di l'architettura Eclipse cù l'esempiu (JDT). A scelta di JDT cum'è un esempiu ùn hè micca accidintali. Questu hè u primu ambiente di sviluppu integratu chì appare in Eclipse. Altri prughjetti *DT Eclipse, cum'è Eclipse C/C++ Development Tooling (CDT), sò stati creati più tardi è piglianu in prestito i principii architettonici basi è i frammenti di codice fonte individuale da JDT. I fundamenti di l'architettura stabilita in JDT sò pertinenti à questu ghjornu per quasi ogni IDE custruitu nantu à a piattaforma Eclipse, cumprese 1C: Strumenti di sviluppu di l'impresa.
Prima di tuttu, deve esse nutatu chì Eclipse hè carattarizatu da una stratificazione architettonica abbastanza chjara, cù a separazione di funziunalità indipendenti da a lingua da a funziunalità pensata per sustene linguaggi di prugrammazione specifichi, è a separazione di cumpunenti "core" indipendenti da UI da cumpunenti assuciati. cù l'interfaccia d'utilizatore di supportu.
Cusì, a piattaforma Eclipse definisce una infrastruttura cumuni, indipendente da a lingua, è i strumenti di sviluppu Java aghjunghjenu un IDE Java cumpletu à Eclipse. Sia a Piattaforma Eclipse è u JDT sò custituiti da parechji cumpunenti, ognuna appartene à un "core" indipendente da UI o à una capa UI (Figura 1).
Risu. 1. Eclipse Platform è JDT
Elenchemu i cumpunenti principali di a piattaforma Eclipse:
- Runtime - Definisce l'infrastruttura plugin. Eclipse hè carattarizatu da una architettura modulare. Essenzialmente, Eclipse hè una cullizzioni di "punti di estensione" è "estensioni".
- Spaziu di travagliu - Gestisce unu o più prughjetti. Un prughjettu hè custituitu di cartulare è schedarii chì sò mappati direttamente à u sistema di schedari.
- Strumentu di Widget Standard (SWT) - Fornisce elementi basi di l'interfaccia d'utilizatore integrati cù u sistema operatore.
- JFace - Fornisce una quantità di quadri di UI custruiti nantu à SWT.
- Oghje - Definisce u paradigma di l'interfaccia utente di Eclipse: editori, viste, prospettive.
Ci vole à dì chì a piattaforma Eclipse furnisce ancu assai altri cumpunenti utili per a custruzzione di strumenti di sviluppu integrati, cumprese Debug, Compare, Search, and Team. Una menzione speciale deve esse fatta di JFace Text - a basa per custruisce "editori intelligenti" di u codice fonte. Sfurtunatamente, ancu un esame superficiale di sti cumpunenti, è ancu di i cumpunenti di a capa UI, ùn hè micca pussibule in u scopu di stu articulu, cusì in u restu di sta sezione ci limiteremu à una panoramica di i principali cumpunenti "core" di a piattaforma Eclipse è JDT.
Core Runtime
L'infrastruttura di plugin Eclipse hè basatu è furnitu da u prugettu . Ogni plugin Eclipse hè un bundle OSGi. A specificazione OSGi definisce, in particulare, i meccanismi per a versione è a risoluzione di a dependenza. In più di sti miccanismi standard, Equinox introduce u cuncettu punti di espansione. Ogni plugin pò definisce i so propri punti di estensione, è ancu intruduce funziunalità supplementari ("extensions") à u sistema utilizendu punti di estensione definiti da u listessu plugins o altri plugins. Ogni descrizzione dettagliata di i meccanismi OSGi è Equinox hè fora di u scopu di stu articulu. Demu solu chì a modularizazione in Eclipse hè tutale (qualsiasi sottosistema, cumpresu Runtime, hè custituitu da unu o più plugins), è quasi tuttu in Eclipse hè una estensione. Inoltre, sti principii sò stati incrustati in l'architettura Eclipse assai prima di l'intruduzioni di OSGi (à quellu tempu anu utilizatu a so propria tecnulugia, assai simili à OSGi).
U spaziu di travagliu core
Quasi ogni ambiente di sviluppu integratu custruitu nantu à a piattaforma Eclipse funziona cù l'area di travagliu Eclipse. Hè u spaziu di travagliu chì generalmente cuntene u codice fonte di l'applicazione sviluppata in l'IDE. U spaziu di travagliu mape direttamente à u sistema di fugliale è hè custituitu di prughjetti chì cuntenenu cartulare è schedari. Sti prughjetti, cartulare è schedari sò chjamati risorse spaziu di travagliu. L'implementazione di u spaziu di travagliu in Eclipse serve cum'è cache in relazione à u sistema di fugliale, chì permette di accelerà significativamente a traversata di l'arbre di risorse. Inoltre, u spaziu di travagliu furnisce una quantità di servizii supplementari, cumprese и .
U cumpunente Core Resources (org.eclipse.core.resources plugin) hè rispunsevuli di sustene u spaziu di travagliu è i so risorse. In particulare, stu cumpunente furnisce l'accessu programmaticu à u spaziu di travagliu in a forma mudelli di risorse. Per travaglià in modu efficace cù stu mudellu, i clienti necessitanu un modu simplice per presentà un ligame à una risorsa. In questu casu, saria desirabile ammuccià l'ughjettu chì guarda direttamente u statu di a risorsa in u mudellu da l'accessu di u cliente. Altrimenti, in u casu di, per esempiu, sguassate un schedariu, u cliente puderia cuntinuà à mantene un ughjettu chì ùn hè più in u mudellu, cù i prublemi chì seguitanu. Eclipse risolve stu prublema usendu qualcosa chjamatu manicura risorsa. Handle agisce cum'è una chjave (cunnosce solu u percorsu à a risorsa in u spaziu di travagliu) è cuntrolla cumplettamente l'accessu à l'ughjettu di u mudellu internu, chì guarda direttamente l'infurmazioni nantu à u statu di a risorsa. Stu disignu hè una variazione di u mudellu .
Risu. A Figura 2 illustra l'idioma Maniglia / Corpu applicata à u mudellu di risorsa. L'interfaccia IResource rapprisenta u manicu di una risorsa è hè una API, à u cuntrariu di a classa Resource, chì implementa sta interfaccia, è a classa ResourceInfo, chì rapprisenta u corpu, chì ùn sò micca API. Enfaticemu chì u manicu cunnosce solu u percorsu à a risorsa relative à a radica di u spaziu di travagliu è ùn cuntene micca un ligame à l'infurmazioni di risorse. L'oggetti di informazioni di risorse formanu un chjamatu "arburu di l'elementu". Sta struttura di dati hè cumplettamente materializzata in memoria. Per truvà l'esempiu di informazioni di risorsa chì currisponde à un manicu, l'arburu di l'elementu hè attraversatu secondu u percorsu guardatu in quellu manicu.
Risu. 2. IResource è ResourceInfo
Comu avemu vistu più tardi, u disignu basu di u mudellu di risorsa (puderemu chjamà basatu in manichi) hè utilizatu in Eclipse ancu per altri mudelli. Per avà, listemu alcune di e proprietà distintive di stu disignu:
- U manicu hè un oggettu di valore. L'oggetti di valore sò oggetti immutabili chì l'ugualità ùn hè micca basatu annantu à l'identità. Tali ogetti ponu esse utilizati in modu sicuru cum'è chjave in cuntenituri hashed. Diversi casi di manicu ponu riferite à a stessa risorsa. Per paragunà elli, avete bisognu di utilizà u metudu uguali (Object).
- Handle definisce u cumpurtamentu di una risorsa, ma ùn cuntene infurmazione nantu à u statu di a risorsa (l'unicu dati chì guarda hè a "chjave", u percorsu à a risorsa).
- Handle pò riferisce à una risorsa chì ùn esiste micca (o una risorsa chì ùn hè micca stata creata, o una risorsa chì hè digià stata sguassata). L'esistenza di una risorsa pò esse verificata cù u metudu IResource.exists().
- Alcune operazioni ponu esse implementate basate solu nantu à l'infurmazioni guardate in u manicu stessu (i cosiddetti operazioni di maniglia solu). Esempii sò IResource.getParent(), getFullPath(), etc. A risorsa ùn hà micca bisognu di esiste per una tale operazione per riesce. L'operazioni chì necessitanu una risorsa per esisti per riesce lattanu una CoreException se a risorsa ùn esiste micca.
Eclipse furnisce un mecanismu efficiente per notificà i cambiamenti di risorse di u spaziu di travagliu (Figura 3). E risorse ponu cambià sia per via di l'azzioni realizati in l'IDE di l'Eclipse stessu sia per u risultatu di a sincronizazione cù u sistema di schedari. In i dui casi, i clienti chì abbonanu à e notificazioni sò furniti cù infurmazioni detallati nantu à i cambiamenti in a forma di "deltas di risorse". Un delta descrive i cambiamenti trà dui stati di una risorsa di u spaziu di travagliu (sub-)arbulu è hè stessu un arbre, ogni node di quale descrive un cambiamentu à una risorsa è cuntene una lista di deltas à u prossimu livellu chì descrizanu cambiamenti à i risorse di u zitellu.
Risu. 3. IResourceChangeEvent è IResourceDelta
U mecanismu di notificazione basatu annantu à i deltas di risorse hà e seguenti caratteristiche:
- Un solu cambiamentu è parechji cambiamenti sò descritti cù a listessa struttura, postu chì u delta hè custruitu cù u principiu di cumpusizioni recursiva. I clienti di l'abbonati ponu processà e notificazioni di cambiamentu di risorse utilizendu una discendenza recursiva attraversu un arbre di delta.
- U delta cuntene infurmazione cumpleta nantu à i cambiamenti à a risorsa, cumpresu u so muvimentu è / o cambiamenti in i "marcatori" assuciati cù questu (per esempiu, l'errore di compilazione sò rapprisentati cum'è marcatori).
- Siccomu e referenze di risorsa sò fatte attraversu u manicu, delta pò naturalmente riferite una risorsa remota.
Cumu vedemu prestu, i cumpunenti principali di u disignu di u mecanismu di notificazione di cambiamentu di u mudellu di risorsa sò ancu pertinenti per altri mudelli basati in manichi.
JDT Core
U mudellu di risorse di u spaziu di travagliu Eclipse hè un mudellu agnosticu di lingua fundamentale. U cumpunente JDT Core (plugin org.eclipse.jdt.core) furnisce una API per navigà è analizà a struttura di u spaziu di travagliu da una perspettiva Java, u chjamatu "mudellu Java" (mudellu Java). Questa API hè definita in termini di elementi Java, in uppusizione à l'API di mudellu di risorsa sottostante, chì hè definitu in termini di cartulare è schedari. L'interfacce principali di l'arburu di l'elementu Java sò mostrati in Fig. 4.
Risu. 4. Elementi di mudelli Java
U mudellu Java usa u listessu idioma di manicu / corpu cum'è u mudellu di risorse (Figura 5). IJavaElement hè u manicu, è JavaElementInfo ghjucà u rolu di corpu. L'interfaccia IJavaElement definisce un protocolu cumunu à tutti l'elementi Java. Certi di i so metudi sò solu manigliati: getElementName(), getParent(), etc. L'ughjettu JavaElementInfo guarda u statu di l'elementu currispundenti: a so struttura è attributi.
Risu. 5. IJavaElement è JavaElementInfo
U mudellu Java hà alcune diffirenzii in l'implementazione di u disignu basu di manicu / corpu cumparatu cù u mudellu di risorse. Comu nutatu sopra, in u mudellu di risorsa, l'arburu di l'elementu, chì i nodi sò l'oggetti d'infurmazioni di risorse, hè sanu sanu in memoria. Ma u mudellu Java pò avè un nùmeru significativamente più grande di elementi chì l'arburu di risorsa, perchè ancu rapprisenta a struttura interna di i schedari .java è .class: tipi, campi è metudi.
Per evitari di materializà cumplettamente l'arburu sanu di elementi in memoria, l'implementazione di u mudellu Java usa una cache LRU di dimensione limitata di l'infurmazioni di l'elementu, induve a chjave hè manighjà IJavaElement. L'oggetti d'informazione di l'elementu sò creati nantu à a dumanda mentre l'arburu di l'elementu hè navigatu. In questu casu, l'articuli menu usati sò sbulicati da a cache, è u cunsumu di memoria di u mudellu resta limitatu à a dimensione di cache specificata. Questu hè un altru vantaghju di u disignu basatu in manicu, chì oculta cumplettamente tali dettagli di implementazione da u codice di u cliente.
U mecanismu per notificà i cambiamenti à l'elementi Java hè in generale simili à u mecanismu per seguità i cambiamenti à e risorse di u spaziu di travagliu discutitu sopra. Un cliente chì vulete monitorà i cambiamenti in u mudellu Java subscribe à notificazioni, chì sò rapprisentati cum'è un oggettu ElementChangedEvent chì cuntene un IJavaElementDelta (Figura 6).
Risu. 6. ElementChangedEvent è IJavaElementDelta
U mudellu Java ùn cuntene micca infurmazione nantu à i corpi di metudu o a risoluzione di nomi, cusì per l'analisi detallatu di u codice scrittu in Java, JDT Core furnisce un mudellu supplementu (non-basatu) : (arburu di sintassi astratta, AST). AST rapprisenta u risultatu di l'analisi di u testu fonte. I nodi AST currispondenu à elementi di a struttura di u modulu fonte (dichjarazioni, operatori, espressioni, etc.) è cuntenenu infurmazioni nantu à e coordenate di l'elementu currispundenti in u testu fonte, è ancu (cum'è una opzione) infurmazione nantu à a risoluzione di u nome a forma di ligami à cusì-chiamatu ligami. Ligami sò oggetti chì rapprisentanu entità chjamate, cum'è tipi, metudi è variàbili, cunnisciuti da u compilatore. A cuntrariu di i nodi AST, chì formanu un arbre, i ligami supportanu i riferimenti incruciati è generalmente formanu un graficu. A classa astratta ASTNode hè a classa di basa cumuni per tutti i nodi AST. I sottoclassi ASTNode currispondenu à custruzzioni sintattiche specifiche di a lingua Java.
Perchè l'arbureti di sintassi ponu cunsumà una quantità significativa di memoria, JDT cache solu un AST per l'editore attivu. A cuntrariu di u mudellu Java, l'AST hè tipicamenti vistu cum'è un mudellu "intermediu", "tempuraneu" chì i membri ùn devenu esse riferiti da i clienti fora di u cuntestu di l'operazione chì hà purtatu à a creazione di l'AST.
I trè mudelli elencati (mudellu Java, AST, associazioni) formanu inseme a basa per custruisce "strumenti di sviluppu intelligenti" in JDT, cumpresu un editore Java putente cù diversi "aiutanti", diverse azzioni per processà u codice fonte (cumprese l'urganizazione di una lista di impurtazioni). nomi è furmatu secondu u stilu persunalizatu), strumenti di ricerca è refactoring. In questu casu, u mudellu Java ghjoca un rolu particulari, postu chì hè quellu chì hè utilizatu com'è a basa per una rapprisintazioni visuale di a struttura di l'applicazione sviluppata (per esempiu, in Package Explorer, Outline, Search, Call Hierarchy, è Tipo Gerarchia).
Cumpunenti di Eclipse utilizati in 1C: Strumenti di Sviluppu di l'Enterprise
In Fig. A Figura 7 mostra i cumpunenti Eclipse chì formanu a fundazione di a piattaforma tecnologica per 1C: Strumenti di Sviluppu di l'Enterprise.
Risu. 7. Eclipse cum'è una piattaforma per 1C: Strumenti di sviluppu di l'impresa
Piattaforma Eclipse furnisce l'infrastruttura di basa. Avemu vistu certi aspetti di sta infrastruttura in a sezione precedente.
(EMF) furnisce un modu generale di mudeli di dati strutturati. EMF hè integrata cù a piattaforma Eclipse, ma pò ancu esse usata separatamente in l'applicazioni Java regulare. Piuttostu spessu, i novi sviluppatori di l'Eclipse sò digià cunnisciuti bè cù EMF, ancu s'ellu ùn anu micca capitu bè l'intricacies di a piattaforma Eclipse. Unu di i mutivi di una popularità cusì meritata hè u disignu universale, chì include, frà altri cose, un API meta-livellu unificatu, chì permette di travaglià cù qualsiasi mudellu EMF in modu generale. L'implementazioni basi per l'oggetti di mudelli furnite da EMF è u sottosistema per a generazione di codice di mudellu basatu annantu à u meta-mudellu aumentanu significativamente a velocità di sviluppu è riduce u numeru di errori. EMF cuntene ancu miccanismi per serializà mudelli, seguite i cambiamenti à u mudellu, è assai di più.
Cum'è qualsiasi strumentu veramente generale, EMF hè adattatu per risolve una larga gamma di prublemi di mudeli, ma alcune classi di mudelli (per esempiu, i mudelli basati nantu à manichi discututi sopra) ponu esse bisognu di strumenti di mudeli più specializati. Parlà di EMF hè un compitu ingrate, soprattuttu in i limiti limitati di un articulu, postu chì questu hè u sughjettu di un libru separatu, è un piuttostu grossu. Ricurdemu solu chì u sistema di generalizazioni d'alta qualità sottu à l'EMF hà permessu a nascita di una serie di prughjetti dedicati à u mudellu, chì sò inclusi in u prughjettu di primu livellu. cù l'EMF stessu. Un tali prughjettu hè Eclipse Xtext.
furnisce una infrastruttura di "modelamentu di testu". Xtext usa per analizà u testu fonte è EMF per rapprisintà l'ASG resultanti (graficu semanticu astrattu, chì hè essenzialmente una cumminazione di AST è associazioni), ancu chjamatu "mudellu semanticu". A grammatica di a lingua modellata da Xtext hè descritta in a lingua propria di Xtext. Questu permette micca solu di generà una descrizzione di grammatica per ANTLR, ma ancu di ottene un mecanismu di serializazione AST (vale à dì Xtext furnisce un parser è un unparser), un suggerimentu di cuntestu, è una quantità di altri cumpunenti di lingua. Per d 'altra banda, a lingua di grammatica utilizata in Xtext hè menu flexible chì, per dì, a lingua di grammatica utilizata in ANTLR. Per quessa, qualchì volta hè necessariu di "piegà" a lingua implementata à Xtext, chì ùn hè di solitu micca un prublema se parlemu di una lingua sviluppata da zero, ma pò esse inaccettabile per e lingue cù una sintassi già stabilita. Malgradu questu, Xtext hè attualmente u strumentu più maturu, riccu di funzioni è versatile in Eclipse per custruisce lingue di prugrammazione è strumenti di sviluppu per elli. In particulare, hè un strumentu ideale per a prototipazione rapida (Lingua specifica di u duminiu, DSL). In più di u "core di lingua" sopra citatu basatu annantu à ANTLR è EMF, Xtext furnisce assai cumpunenti utili di livellu più altu, cumpresi i miccanismi di indexazione, a custruzzione incrementale, un "editore intelligente", è assai, assai di più, ma lascia fora di maniglia. mudelli di lingua basatu. Cum'è EMF, Xtext hè un sughjettu degnu di un libru separatu, è ùn pudemu mancu appena brevemente parlà di tutte e so capacità avà.
1C: Strumenti di sviluppu di l'impresa utilizanu attivamente l'EMF stessu è una quantità di altri prughjetti di Modelling Eclipse. In particulare, Xtext hè unu di i fundamenti di strumenti di sviluppu per tali lingue 1C: Enterprise cum'è a lingua di prugrammazione integrata è a lingua di dumanda. Un'altra basa per questi strumenti di sviluppu hè u prughjettu Eclipse Handly, chì discutemu in più detail (di i cumpunenti Eclipse listati, hè sempre u menu cunnisciutu).
, un sottuprogettu di u prughjettu di u primu livellu di l'Eclipse Technology, emersu com'è u risultatu di una cuntribuzione iniziale di codice à a Fundazione Eclipse fatta da 1C in 2014. Dapoi tandu, 1C hà cuntinuatu à sustene u sviluppu di u prugettu: i committers Handly sò impiegati di a cumpagnia. U prugettu hè chjucu, ma occupa un nichu piuttostu unicu in Eclipse: u so scopu principale hè di sustene u sviluppu di mudelli basati in manicu.
I principii architetturali basi di mudelli basati in manichi, cum'è l'idioma di manicu / corpu, sò stati discututi sopra cù u mudellu di risorse è u mudellu Java cum'è esempi. Hà nutatu ancu chì u mudellu di risorsa è u mudellu Java sò fundamenti impurtanti per i strumenti di sviluppu Eclipse Java (JDT). E postu chì quasi tutti i prughjetti *DT Eclipse anu una architettura simile à JDT, ùn saria micca una grande esagerazione per dì chì i mudelli basati in manichi sò sottumessi à parechji, se micca tutti l'IDE custruiti nantu à a piattaforma Eclipse. Per esempiu, l'Eclipse C/C++ Development Tooling (CDT) hà un mudellu C/C++ basatu in manicu chì ghjoca u listessu rolu in l'architettura CDT cum'è u mudellu Java in u JDT.
Prima di Handly, Eclipse ùn offre micca biblioteche specializate per custruisce mudelli di lingua basati in manichi. I mudelli chì esistenu attualmente sò stati creati principarmenti adattendu direttamente u codice di u mudellu Java (aka copia / incolla), in i casi induve permette Eclipse Public License (EPL). (Ovviamente, questu ùn hè di solitu micca un prublema legale per, dì, Eclipse prughjetti stessu, ma micca per i prudutti di fonte chjusu.) In più di a so inherente casualità, sta tecnica introduce prublemi cunnisciuti: duplicazione di codice introduttu da quandu si adatta à l'errori, ecc. U peghju hè chì i mudelli resultanti fermanu "cose in elli" è ùn prufittà micca di u putenziale di unificazione. Ma l'isulazione di cuncetti cumuni è protokolli per i mudelli di lingua basati in manicu puderia guidà à a creazione di cumpunenti reutilizabili per travaglià cun elli, simili à ciò chì hè accadutu in u casu di EMF.
Ùn hè micca chì Eclipse ùn hà micca capitu sti prublemi. Torna in u 2005 , riassuntu l'esperienza di sviluppà u prototipu CDT, a necessità di creà una infrastruttura cumuna per i mudelli di lingua, cumpresi i mudelli basati in manichi. Ma, cum'è spessu succèri, per via di i travaglii di priorità più altu, l'implementazione di sti idee ùn hè mai arrivatu. Intantu, a factorizazione di u codice * DT hè sempre unu di i temi sottosviluppati in Eclipse.
In un certu sensu, u prughjettu Handly hè pensatu per risolve apprussimatamente i stessi prublemi cum'è EMF, ma per i mudelli basati nantu à manicu, è principalmente quelli di lingua (vale à dì, chì rapprisentanu elementi di a struttura di qualchì lingua di prugrammazione). I scopi principali stabiliti per u disignu di Handly sò elencati quì sottu:
- Identificazione di i principali astrazioni di u sughjettu.
- Riduzzione di u sforzu è migliurà a qualità di implementazione di mudelli di lingua basati in manicu per mezu di reutilizazione di codice.
- Fornisce una API di meta-livellu unificata à i mudelli resultanti, chì permette di creà cumpunenti IDE cumuni chì travaglianu cù mudelli basati in lingua.
- Flessibilità è scalabilità.
- Integrazione cù Xtext (in una capa separata).
Per mette in risaltu cuncetti è protokolli cumuni, sò stati analizati implementazioni esistenti di mudelli basati in manichi di lingua. L'interfacce principali è l'implementazioni basi furnite da Handly sò mostrati in Fig. 8.
Risu. 8. Interfacce cumuni è implementazioni basi di elementi Handly
L'interfaccia IElement rapprisenta u manicu di un elementu è hè cumuna à elementi di tutti i mudelli Handly-based. A classa astratta Elementu implementa u mecanismu di manicu / corpu generale (Fig. 9).
Risu. 9. IElement è maniglia generica / implementazione di corpu
Inoltre, Handly furnisce un mecanismu generalizatu per notificà i cambiamenti in l'elementi di u mudellu (Fig. 10). Comu pudete vede, hè largamente simili à i meccanismi di notificazione implementati in u mudellu di risorsa è u mudellu Java, è usa IElementDelta per furnisce una rapprisintazioni unificata di l'infurmazioni di cambiamentu di l'elementu.
Risu. 10. Interfacce generale è implementazioni basi di u mecanismu di notificazione Handly
A parte Handly discussa sopra (Fig. 9 è 10) pò esse usata per rapprisintà quasi tutti i mudelli basati in manicu. Per creà linguisticu mudelli, u prugettu offre funziunalità supplementari - in particulare, interfacce cumuni è implementazioni basi per elementi di a struttura di u testu fonte, u cusì chjamatu elementi fonte (Fig. 8). L'interfaccia ISourceFile rapprisenta un schedariu fonte, è ISourceConstruct rapprisenta un elementu in u schedariu fonte. I classi astratti SourceFile è SourceConstruct implementanu meccanismi generalizati per sustene u travagliu cù i fugliali d'origine è i so elementi, per esempiu, travagliendu cù buffer di testu, vincendu à e coordenate di un elementu in u testu fonte, cunciliendu mudelli cù u cuntenutu attuale di un buffer di copia di travagliu. , etc. L'implementazione di sti meccanismi hè di solitu abbastanza una sfida, è Handly pò riduce significativamente l'sforzu di sviluppà mudelli di lingua basati nantu à manicu furnisce implementazioni basi di alta qualità.
In più di i meccanismi core elencati sopra, Handly furnisce una infrastruttura per buffer di testu è snapshots, supportu per l'integrazione cù editori di codice fonte (cumpresa l'integrazione fora di a scatula cù l'editor Xtext), è ancu alcuni cumpunenti UI cumuni chì travaglià cù editori di codice fonte. Modelli manuali cum'è un framework di schema. Per illustrà e so capacità, u prughjettu furnisce parechji esempi, cumpresa una implementazione di u mudellu Java in Handly. (In cunfrontu cù l'implementazione cumpleta di u mudellu Java in JDT, stu mudellu hè intenzionalmente un pocu simplificatu per più chiarezza).
Comu nutatu prima, un focusu maiò durante u disignu iniziale di Handly è u sviluppu sussegwente era è cuntinueghja à esse in scalabilità è flessibilità.
In principiu, i mudelli basati in manicu scala abbastanza bè "per design". Per esempiu, l'idioma manicu / corpu permette di limità a quantità di memoria cunsumata da un mudellu. Ma ci sò ancu sfumature. Cusì, quandu teste Handly per scalabilità, un prublema hè statu scupertu in l'implementazione di u mecanismu di notificazione - quandu un gran numaru d'elementi sò stati cambiati, a custruzzione di delta hà pigliatu troppu tempu. Risultava chì u listessu prublema era presente in u mudellu JDT Java, da quale u codice currispundente hè statu adattatu una volta. Fixemu u bug in Handly è preparatu un patch simili per JDT, chì hè statu ricevutu gratamente. Questu hè solu un esempiu induve l'introduzione di Handly in implementazioni di mudelli esistenti puderia esse potenzialmente utile, perchè in questu casu un tali bug puderia esse riparatu in un solu locu.
Per fà l'implementazione di Handly in implementazioni di mudelli esistenti tecnicamente fattibili, a biblioteca deve avè una flessibilità significativa. U prublema principali hè di mantene a cumpatibilità retroattiva in u mudellu API. Stu prublema hè stata risolta in separà chjaramente l'API di mudellu specificu, definitu è cumpletamente cuntrullatu da u sviluppatore, da l'API di meta-livellu unificatu furnita da a biblioteca. Questu ùn solu rende tecnicamente pussibule di implementà Handly in implementazioni esistenti, ma dà ancu à u novu sviluppatore di mudelli una libertà significativa quandu cuncepisce l'API.
A flessibilità hà ancu altri aspetti. Per esempiu, Handly impone guasi nisuna restrizioni à a struttura di u mudellu è pò esse usatu per mudificà sia e lingue di u scopu generale sia di u duminiu specificu. Quandu custruì a struttura di u schedariu fonte, Handly ùn prescriva alcuna forma particulari di rapprisintazioni AST è, in principiu, ùn esige mancu a presenza di un AST stessu, assicurendu cusì a cumpatibilità cù quasi ogni mecanismu di analisi. Infine, Handly supporta l'integrazione cumpleta cù l'area di travagliu Eclipse, ma pò ancu travaglià direttamente cù i sistemi di fugliale grazie à a so integrazione cù (EFS).
Versione attuale esce in dicembre 2016. Malgradu u fattu chì u prugettu hè attualmente in un statu d'incubazione è l'API ùn hè micca stata definitivamente riparata, Handly hè digià utilizatu in dui grandi prudutti cummerciale chì anu pigliatu u risicu di agisce cum'è "early adopters", è, devi dì, ùn ne dispiace ancu.
Comu nutatu sopra, unu di sti prudutti hè 1C: Strumenti di sviluppu di l'impresa, induve Handly hè utilizatu da u principiu per mudificà elementi di a struttura d'altu livellu di tali 1C: Lingue di l'impresa cum'è a lingua di prugrammazione integrata è a lingua di dumanda. . Un altru pruduttu hè menu cunnisciutu da u publicu generale. Questu , un ambiente di cuncepimentu integratu per un processore di set di istruzioni specifiche per l'applicazione (ASIP), utilizatu sia in a cumpagnia ceca Codasip stessu sia da i so clienti, cumprese , , , . Codasip hà utilizatu Handly in a produzzione da u 2015, cuminciendu cù a versione Handly 0.2. L'ultima versione di Codasip Studio usa a versione 0.5, liberata in ghjugnu 2016. Ondřej Ilčík, chì guida u sviluppu IDE in Codasip, hè in cuntattu cù u prugettu, furnisce un feedback vitale in nome di "l'adopru di terzu". Hè statu ancu capaci di truvà un pocu di tempu liberu per participà direttamente à u sviluppu di u prugettu, implementendu una capa UI (~ 4000 linee di codice) per unu di l'esempii Handly, un mudellu Java. Infurmazioni più dettagliate di prima manu nantu à l'usu di Handly da l'adoptori ponu esse truvate nantu à a pagina prughjettu.
Speremu chì dopu à a liberazione di a versione 1.0 cù una guaranzia di stabilità API è u prughjettu chì abbanduneghja u statu d'incubazione, Handly avarà novi adoptatori. Intantu, u prugettu cuntinueghja à pruvà è à migliurà ulteriormente l'API, rilascendu duie versioni "principali" per annu - in ghjugnu (a listessa data di a liberazione simultanea di Eclipse) è dicembre, chì furnisce un calendariu prevedibile chì l'adoptori ponu cunfidà. Pudemu ancu aghjunghje chì a "tassa di bug" di u prughjettu ferma à un livellu constantemente bassu è Handly hà travagliatu in modu affidabile in i prudutti di i primi adoptanti dapoi e prime versioni. Per scopre più Eclipse Handly, pudete aduprà и .
Source: www.habr.com