mungkin, telah lama tidak memerlukan pengenalan khas. Ramai orang biasa dengan Eclipse terima kasih kepada alat pembangunan Eclipse Java (). IDE Java sumber terbuka yang popular inilah yang kebanyakan pembangun kaitkan dengan perkataan "Eclipse". Walau bagaimanapun, Eclipse ialah platform yang boleh diperluaskan untuk menyepadukan alatan pembangunan (Platform Eclipse) dan beberapa IDE yang dibina berdasarkannya, termasuk JDT. Eclipse ialah kedua-dua Projek Eclipse, projek peringkat tertinggi yang menyelaraskan pembangunan Platform Eclipse dan JDT, dan Eclipse SDK, hasil yang disampaikan daripada pembangunan itu. Akhir sekali, Eclipse ialah Yayasan sumber terbuka dengan komuniti projek yang besar, tidak semuanya ditulis dalam Java atau berkaitan dengan alat pembangunan (contohnya, projek ΠΈ ). Dunia Eclipse sangat pelbagai.
Dalam artikel ini, yang merupakan gambaran keseluruhan, kami akan cuba melihat beberapa asas seni bina Eclipse sebagai platform untuk membina alat pembangunan bersepadu dan memberi idea awal tentang komponen Eclipse yang membentuk asas teknologi. platform untuk "Konfigurator baharu" 1C: Perusahaan. . Sudah tentu, semakan sedemikian tidak dapat dielakkan sebahagian besarnya dangkal dan agak terhad, termasuk kerana kami memfokuskan bukan sahaja pada pembangun Eclipse sebagai khalayak sasaran. Walau bagaimanapun, kami berharap walaupun pembangun Eclipse yang berpengalaman akan dapat mencari maklumat menarik dalam artikel tersebut. Sebagai contoh, kita akan bercakap tentang salah satu "rahsia Eclipse", projek yang agak baru dan kurang diketahui , yang diasaskan dan disokong oleh 1C.
Pengenalan kepada Eclipse Architecture
Mari kita lihat beberapa aspek umum seni bina Eclipse menggunakan contoh (JDT). Pemilihan JDT sebagai contoh bukanlah secara kebetulan. Ini ialah persekitaran pembangunan bersepadu pertama yang muncul dalam Eclipse. Projek *DT Eclipse yang lain, seperti Eclipse C/C++ Development Tooling (CDT), telah dibuat kemudian dan meminjam kedua-dua prinsip asas seni bina dan serpihan kod sumber individu daripada JDT. Asas seni bina yang ditetapkan dalam JDT adalah relevan sehingga hari ini untuk hampir mana-mana IDE yang dibina di atas Platform Eclipse, termasuk 1C:Enterprise Development Tools.
Pertama sekali, perlu diingatkan bahawa Eclipse dicirikan oleh lapisan seni bina yang agak jelas, dengan pemisahan fungsi bebas bahasa daripada fungsi yang direka untuk menyokong bahasa pengaturcaraan tertentu, dan pemisahan komponen "teras" bebas UI daripada komponen yang berkaitan. dengan antara muka pengguna yang menyokong.
Oleh itu, Platform Eclipse mentakrifkan infrastruktur bebas bahasa yang lazim, dan alatan pembangunan Java menambah IDE Java berciri penuh kepada Eclipse. Kedua-dua Platform Eclipse dan JDT terdiri daripada beberapa komponen, setiap satunya tergolong dalam "teras" bebas UI atau lapisan UI (Rajah 1).
nasi. 1. Platform Eclipse dan JDT
Mari kita senaraikan komponen utama Platform Eclipse:
- Runtime β Mentakrifkan infrastruktur pemalam. Eclipse dicirikan oleh seni bina modular. Pada asasnya, Eclipse ialah koleksi "titik lanjutan" dan "sambungan".
- Ruang kerja β Menguruskan satu atau lebih projek. Projek terdiri daripada folder dan fail yang dipetakan terus ke sistem fail.
- Kit Alat Widget Standard (SWT) - Menyediakan elemen antara muka pengguna asas yang disepadukan dengan sistem pengendalian.
- JFace β Menyediakan beberapa rangka kerja UI yang dibina di atas SWT.
- Workbench β Mentakrifkan paradigma UI Eclipse: editor, pandangan, perspektif.
Perlu dikatakan bahawa Platform Eclipse juga menyediakan banyak komponen berguna lain untuk membina alat pembangunan bersepadu, termasuk Nyahpepijat, Bandingkan, Cari dan Pasukan. Sebutan khusus harus dibuat tentang Teks JFace - asas untuk membina "editor pintar" kod sumber. Malangnya, walaupun pemeriksaan sepintas lalu bagi komponen ini, serta komponen lapisan UI, tidak boleh dilakukan dalam skop artikel ini, jadi dalam baki bahagian ini, kami akan mengehadkan diri kami kepada gambaran keseluruhan komponen "teras" utama Platform Eclipse dan JDT.
Masa Jalanan Teras
Infrastruktur pemalam Eclipse adalah berdasarkan dan disediakan oleh projek . Setiap pemalam Eclipse ialah berkas OSGi. Spesifikasi OSGi mentakrifkan, khususnya, mekanisme untuk versi dan resolusi pergantungan. Sebagai tambahan kepada mekanisme standard ini, Equinox memperkenalkan konsep tersebut titik pengembangan. Setiap pemalam boleh menentukan titik sambungannya sendiri, dan juga memperkenalkan fungsi tambahan (βsambunganβ) kepada sistem menggunakan titik sambungan yang ditakrifkan oleh pemalam yang sama atau lain-lain. Sebarang penerangan terperinci tentang mekanisme OSGi dan Equinox adalah di luar skop artikel ini. Mari kita ambil perhatian bahawa modularisasi dalam Eclipse adalah jumlah (mana-mana subsistem, termasuk Runtime, terdiri daripada satu atau lebih pemalam), dan hampir semua dalam Eclipse ialah sambungan. Selain itu, prinsip-prinsip ini telah tertanam dalam seni bina Eclipse lama sebelum pengenalan OSGi (pada masa itu mereka menggunakan teknologi mereka sendiri, hampir sama dengan OSGi).
Ruang Kerja Teras
Hampir mana-mana persekitaran pembangunan bersepadu yang dibina di atas Platform Eclipse berfungsi dengan ruang kerja Eclipse. Ia adalah ruang kerja yang biasanya mengandungi kod sumber aplikasi yang dibangunkan dalam IDE. Ruang kerja memetakan terus ke sistem fail dan terdiri daripada projek yang mengandungi folder dan fail. Projek, folder dan fail ini dipanggil sumber ruang kerja. Pelaksanaan ruang kerja dalam Eclipse berfungsi sebagai cache berhubung dengan sistem fail, yang memungkinkan untuk mempercepatkan traversan pepohon sumber dengan ketara. Di samping itu, ruang kerja menyediakan beberapa perkhidmatan tambahan, termasuk ΠΈ .
Komponen Sumber Teras (org.eclipse.core.resources plugin) bertanggungjawab untuk menyokong ruang kerja dan sumbernya. Khususnya, komponen ini menyediakan akses terprogram kepada ruang kerja dalam bentuk model sumber. Untuk bekerja dengan berkesan dengan model ini, pelanggan memerlukan cara mudah untuk membentangkan pautan ke sumber. Dalam kes ini, adalah wajar untuk menyembunyikan objek yang menyimpan secara langsung keadaan sumber dalam model daripada akses klien. Jika tidak, dalam kes, sebagai contoh, memadamkan fail, pelanggan boleh terus memegang objek yang tiada lagi dalam model, dengan masalah yang seterusnya. Eclipse menyelesaikan masalah ini menggunakan sesuatu yang dipanggil mengendalikan sumber. Handle bertindak sebagai kunci (ia hanya mengetahui laluan ke sumber dalam ruang kerja) dan mengawal sepenuhnya akses kepada objek model dalaman, yang secara langsung menyimpan maklumat tentang keadaan sumber. Reka bentuk ini adalah variasi corak .
nasi. Rajah 2 menggambarkan simpulan bahasa Handle/Body seperti yang digunakan pada model sumber. Antara muka IResource mewakili pemegang sumber dan merupakan API, tidak seperti kelas Sumber, yang melaksanakan antara muka ini dan kelas ResourceInfo, yang mewakili badan, yang bukan API. Kami menekankan bahawa pemegang hanya mengetahui laluan ke sumber berbanding akar ruang kerja dan tidak mengandungi pautan ke maklumat sumber. Objek maklumat sumber membentuk apa yang dipanggil "pokok elemen". Struktur data ini terwujud sepenuhnya dalam ingatan. Untuk mencari contoh maklumat sumber yang sepadan dengan pemegang, pepohon elemen dilalui mengikut laluan yang disimpan dalam pemegang itu.
nasi. 2. IResource dan ResourceInfo
Seperti yang akan kita lihat kemudian, reka bentuk asas model sumber (kita mungkin memanggilnya berasaskan pemegang) digunakan dalam Eclipse untuk model lain juga. Buat masa ini, mari kita senaraikan beberapa ciri tersendiri reka bentuk ini:
- Pemegang ialah objek nilai. Objek nilai ialah objek tidak berubah yang persamaannya tidak berdasarkan identiti. Objek sedemikian boleh digunakan dengan selamat sebagai kunci dalam bekas cincang. Beberapa contoh pemegang boleh merujuk sumber yang sama. Untuk membandingkannya, anda perlu menggunakan kaedah equals(Object).
- Handle mentakrifkan kelakuan sumber, tetapi tidak mengandungi maklumat tentang keadaan sumber (satu-satunya data yang disimpan ialah "kunci", laluan ke sumber).
- Handle boleh merujuk kepada sumber yang tidak wujud (sama ada sumber yang belum dicipta atau sumber yang telah dipadamkan). Kewujudan sumber boleh disemak menggunakan kaedah IResource.exists().
- Sesetengah operasi boleh dilaksanakan berdasarkan maklumat yang disimpan dalam pemegang itu sendiri (yang dipanggil operasi pemegang sahaja). Contohnya ialah IResource.getParent(), getFullPath(), dsb. Sumber tidak perlu wujud untuk operasi sedemikian berjaya. Operasi yang memerlukan sumber wujud untuk berjaya membuang CoreException jika sumber itu tidak wujud.
Eclipse menyediakan mekanisme yang cekap untuk memberitahu perubahan sumber ruang kerja (Rajah 3). Sumber boleh berubah sama ada akibat tindakan yang dilakukan dalam Eclipse IDE itu sendiri atau akibat penyegerakan dengan sistem fail. Dalam kedua-dua kes, pelanggan yang melanggan pemberitahuan diberikan maklumat terperinci tentang perubahan dalam bentuk "delta sumber". Delta menerangkan perubahan antara dua keadaan pokok sumber ruang kerja (sub-) dan merupakan pokok itu sendiri, setiap nodnya menerangkan perubahan kepada sumber dan mengandungi senarai delta pada peringkat seterusnya yang menerangkan perubahan kepada sumber kanak-kanak.
nasi. 3. IResourceChangeEvent dan IResourceDelta
Mekanisme pemberitahuan berdasarkan delta sumber mempunyai ciri-ciri berikut:
- Satu perubahan dan banyak perubahan diterangkan menggunakan struktur yang sama, kerana delta dibina menggunakan prinsip komposisi rekursif. Pelanggan pelanggan boleh memproses pemberitahuan perubahan sumber menggunakan turunan rekursif melalui pokok delta.
- Delta mengandungi maklumat lengkap tentang perubahan kepada sumber, termasuk pergerakannya dan/atau perubahan dalam "penanda" yang dikaitkan dengannya (contohnya, ralat kompilasi diwakili sebagai penanda).
- Memandangkan rujukan sumber dibuat melalui pemegang, delta secara semula jadi boleh merujuk sumber jauh.
Seperti yang akan kita lihat tidak lama lagi, komponen utama reka bentuk mekanisme pemberitahuan perubahan model sumber juga relevan untuk model berasaskan pemegang yang lain.
Teras JDT
Model sumber ruang kerja Eclipse ialah model agnostik bahasa asas. Komponen Teras JDT (plugin org.eclipse.jdt.core) menyediakan API untuk menavigasi dan menganalisis struktur ruang kerja dari perspektif Java, yang dipanggil "model Java" (model Java). API ini ditakrifkan dari segi unsur Java, berbanding dengan API model sumber asas, yang ditakrifkan dari segi folder dan fail. Antara muka utama pokok elemen Java ditunjukkan dalam Rajah. 4.
nasi. 4. Elemen Model Java
Model Java menggunakan simpulan bahasa pemegang/badan yang sama seperti model sumber (Rajah 5). IJavaElement ialah pemegang, dan JavaElementInfo memainkan peranan badan. Antara muka IJavaElement mentakrifkan protokol yang biasa kepada semua elemen Java. Beberapa kaedahnya adalah pemegang sahaja: getElementName(), getParent(), dsb. Objek JavaElementInfo menyimpan keadaan elemen yang sepadan: struktur dan atributnya.
nasi. 5. IJavaElement dan JavaElementInfo
Model Java mempunyai beberapa perbezaan dalam pelaksanaan reka bentuk pemegang/badan asas berbanding dengan model sumber. Seperti yang dinyatakan di atas, dalam model sumber, pokok elemen, yang nodnya ialah objek maklumat sumber, terkandung sepenuhnya dalam ingatan. Tetapi model Java boleh mempunyai bilangan elemen yang jauh lebih besar daripada pepohon sumber, kerana ia juga mewakili struktur dalaman fail .java dan .class: jenis, medan dan kaedah.
Untuk mengelak daripada merealisasikan keseluruhan pokok elemen dalam ingatan, pelaksanaan model Java menggunakan cache LRU saiz terhad bagi maklumat elemen, di mana kuncinya adalah mengendalikan IJavaElement. objek maklumat unsur dicipta atas permintaan kerana pepohon elemen dilayari. Dalam kes ini, item yang paling kurang kerap digunakan akan dikeluarkan daripada cache, dan penggunaan memori model kekal terhad kepada saiz cache yang ditentukan. Ini adalah satu lagi kelebihan reka bentuk berasaskan pemegang, yang menyembunyikan sepenuhnya butiran pelaksanaan tersebut daripada kod klien.
Mekanisme untuk memberitahu perubahan kepada elemen Java secara umum adalah serupa dengan mekanisme untuk menjejaki perubahan kepada sumber ruang kerja yang dibincangkan di atas. Pelanggan yang ingin memantau perubahan dalam model Java melanggan pemberitahuan, yang diwakili sebagai objek ElementChangedEvent yang mengandungi IJavaElementDelta (Rajah 6).
nasi. 6. ElementChangedEvent dan IJavaElementDelta
Model Java tidak mengandungi maklumat tentang badan kaedah atau resolusi nama, jadi untuk analisis terperinci kod yang ditulis dalam Java, JDT Core menyediakan model tambahan (bukan berasaskan pemegang): (pokok sintaks abstrak, AST). AST mewakili hasil menghurai teks sumber. Nod AST sepadan dengan elemen struktur modul sumber (pengisytiharan, pengendali, ungkapan, dll.) dan mengandungi maklumat tentang koordinat elemen yang sepadan dalam teks sumber, serta (sebagai pilihan) maklumat tentang resolusi nama dalam bentuk pautan kepada apa yang dipanggil pengikatan. Pengikatan ialah objek yang mewakili entiti yang dinamakan, seperti jenis, kaedah dan pembolehubah, yang diketahui oleh pengkompil. Tidak seperti nod AST, yang membentuk pokok, pengikatan menyokong rujukan silang dan secara amnya membentuk graf. Kelas abstrak ASTNode ialah kelas asas biasa untuk semua nod AST. Subkelas ASTNode sepadan dengan binaan sintaksis khusus bahasa Java.
Oleh kerana pepohon sintaks boleh menggunakan sejumlah besar memori, JDT hanya menyimpan satu AST untuk editor aktif. Berbeza dengan model Java, AST biasanya dilihat sebagai model "perantaraan," "sementara" yang ahlinya tidak sepatutnya dirujuk oleh pelanggan di luar konteks operasi yang membawa kepada penciptaan AST.
Tiga model yang disenaraikan (model Java, AST, bindings) bersama-sama membentuk asas untuk membina "alat pembangunan pintar" dalam JDT, termasuk editor Java yang berkuasa dengan pelbagai "pembantu", pelbagai tindakan untuk memproses kod sumber (termasuk mengatur senarai import nama dan pemformatan mengikut gaya tersuai), alat carian dan pemfaktoran semula. Dalam kes ini, model Java memainkan peranan khas, kerana ialah yang digunakan sebagai asas untuk perwakilan visual struktur aplikasi yang sedang dibangunkan (contohnya, dalam Package Explorer, Outline, Search, Call Hierarchy, dan Hierarki Jenis).
Komponen Eclipse yang digunakan dalam 1C:Enterprise Developments Tools
Dalam Rajah. Rajah 7 menunjukkan komponen Eclipse yang membentuk asas platform teknologi untuk 1C:Enterprise Development Tools.
nasi. 7. Eclipse sebagai platform untuk 1C:Enterprise Development Tools
Platform Eclipse menyediakan infrastruktur asas. Kami melihat beberapa aspek infrastruktur ini dalam bahagian sebelumnya.
(EMF) menyediakan cara umum untuk memodelkan data berstruktur. EMF disepadukan dengan Platform Eclipse, tetapi juga boleh digunakan secara berasingan dalam aplikasi Java biasa. Selalunya, pembangun Eclipse baharu sudah mengenali EMF, walaupun mereka belum memahami sepenuhnya selok-belok Platform Eclipse. Salah satu sebab untuk populariti yang sewajarnya adalah reka bentuk universal, yang termasuk, antara lain, API peringkat meta bersatu, yang membolehkan anda bekerja dengan mana-mana model EMF secara umum. Pelaksanaan asas untuk objek model yang disediakan oleh EMF dan subsistem untuk menjana kod model berdasarkan model meta dengan ketara meningkatkan kelajuan pembangunan dan mengurangkan bilangan ralat. EMF juga mengandungi mekanisme untuk mensiri model, menjejaki perubahan pada model dan banyak lagi.
Seperti mana-mana alat yang benar-benar tujuan am, EMF sesuai untuk menyelesaikan pelbagai masalah pemodelan, tetapi sesetengah kelas model (contohnya, model berasaskan pemegang yang dibincangkan di atas) mungkin memerlukan alat pemodelan yang lebih khusus. Bercakap tentang EMF adalah tugas yang tidak berguna, terutamanya dalam had terhad satu artikel, kerana ini adalah subjek buku yang berasingan, dan yang agak tebal. Mari kita ambil perhatian bahawa sistem generalisasi berkualiti tinggi yang mendasari EMF membenarkan kelahiran pelbagai projek khusus untuk pemodelan, yang termasuk dalam projek peringkat atasan. bersama-sama dengan EMF itu sendiri. Satu projek sedemikian ialah Eclipse Xtext.
menyediakan infrastruktur "pemodelan teks". Xtext menggunakan untuk menghuraikan teks sumber dan EMF untuk mewakili ASG yang terhasil (graf semantik abstrak, yang pada asasnya merupakan gabungan AST dan pengikatan), juga dipanggil "model semantik". Tatabahasa bahasa model Xtext diterangkan dalam bahasa Xtext sendiri. Ini membolehkan anda bukan sahaja menjana perihalan tatabahasa untuk ANTLR, tetapi juga untuk mendapatkan mekanisme penyirian AST (iaitu Xtext menyediakan kedua-dua penghurai dan unparser), pembayang konteks dan beberapa komponen bahasa lain. Sebaliknya, bahasa tatabahasa yang digunakan dalam Xtext adalah kurang fleksibel daripada, katakan, bahasa tatabahasa yang digunakan dalam ANTLR. Oleh itu, kadangkala perlu untuk "membengkokkan" bahasa yang dilaksanakan kepada Xtext, yang biasanya tidak menjadi masalah jika kita bercakap tentang bahasa yang dibangunkan dari awal, tetapi mungkin tidak boleh diterima untuk bahasa dengan sintaks yang telah ditetapkan. Walaupun begitu, Xtext pada masa ini ialah alat yang paling matang, lengkap ciri, dan tujuan umum dalam Eclipse untuk membina bahasa pengaturcaraan dan alat pembangunan untuk mereka. Khususnya, ia adalah alat yang ideal untuk prototaip pantas (bahasa khusus domain, DSL). Sebagai tambahan kepada "teras bahasa" yang disebutkan di atas berdasarkan ANTLR dan EMF, Xtext menyediakan banyak komponen peringkat lebih tinggi yang berguna, termasuk mekanisme pengindeksan, pembinaan tambahan, "editor pintar", dan banyak lagi, tetapi meninggalkan pegangan- model bahasa berasaskan. Seperti EMF, Xtext ialah subjek yang layak untuk buku yang berasingan, dan kita hampir tidak boleh bercakap secara ringkas tentang semua keupayaannya sekarang.
1C:Enterprise Development Tools secara aktif menggunakan kedua-dua EMF itu sendiri dan beberapa projek Pemodelan Eclipse yang lain. Khususnya, Xtext ialah salah satu asas alat pembangunan untuk bahasa 1C:Enterprise seperti bahasa pengaturcaraan dan bahasa pertanyaan terbina dalam. Asas lain untuk alat pembangunan ini ialah projek Eclipse Handly, yang akan kami bincangkan dengan lebih terperinci (daripada komponen Eclipse yang disenaraikan, ia masih paling kurang diketahui).
, subprojek projek peringkat tinggi Eclipse Technology, muncul hasil sumbangan kod awal kepada Eclipse Foundation yang dibuat oleh 1C pada 2014. Sejak itu, 1C terus menyokong pembangunan projek: Komitmen handly adalah pekerja syarikat. Projek ini kecil, tetapi ia menduduki niche yang agak unik dalam Eclipse: matlamat utamanya adalah untuk menyokong pembangunan model berasaskan pemegang.
Prinsip seni bina asas model berasaskan pemegang, seperti simpulan bahasa pemegang/badan, telah dibincangkan di atas menggunakan model sumber dan model Java sebagai contoh. Ia juga menyatakan bahawa kedua-dua model sumber dan model Java adalah asas penting untuk alat pembangunan Eclipse Java (JDT). Dan memandangkan hampir semua projek *DT Eclipse mempunyai seni bina yang serupa dengan JDT, tidaklah keterlaluan untuk mengatakan bahawa model berasaskan pemegang mendasari banyak, jika tidak semua IDE yang dibina di atas Platform Eclipse. Contohnya, Eclipse C/C++ Development Tooling (CDT) mempunyai model C/C++ berasaskan pemegang yang memainkan peranan yang sama dalam seni bina CDT seperti model Java dalam JDT.
Sebelum Handly, Eclipse tidak menawarkan perpustakaan khusus untuk membina model bahasa berasaskan pemegang. Model yang wujud pada masa ini dicipta terutamanya dengan menyesuaikan kod model Java secara langsung (aka copy/paste), dalam kes di mana ia membenarkan Lesen Awam Eclipse (EPL). (Jelas sekali, ini biasanya bukan isu undang-undang untuk, katakan, Eclipse memproyeksikan sendiri, tetapi bukan untuk produk sumber tertutup.) Di samping ketidakseimbangan yang wujud, teknik ini memperkenalkan masalah yang terkenal: pertindihan kod yang diperkenalkan oleh apabila menyesuaikan diri dengan ralat, dan lain-lain. Apa yang lebih buruk ialah model yang dihasilkan kekal sebagai "perkara dalam diri mereka sendiri" dan tidak mengambil kesempatan daripada potensi untuk penyatuan. Tetapi mengasingkan konsep dan protokol biasa untuk model bahasa berasaskan pemegang boleh membawa kepada penciptaan komponen boleh guna semula untuk bekerja dengannya, sama seperti yang berlaku dalam kes EMF.
Bukannya Eclipse tidak memahami isu ini. Kembali pada tahun 2005 , meringkaskan pengalaman membangunkan prototaip CDT, keperluan untuk mewujudkan infrastruktur umum untuk model bahasa, termasuk model berasaskan pemegang. Tetapi, seperti yang sering berlaku, disebabkan tugas keutamaan yang lebih tinggi, pelaksanaan idea-idea ini tidak pernah mencapainya. Sementara itu, pemfaktoran kod *DT masih merupakan salah satu topik yang kurang dibangunkan dalam Eclipse.
Dalam erti kata tertentu, projek Handly direka untuk menyelesaikan lebih kurang masalah yang sama seperti EMF, tetapi untuk model berasaskan pemegang, dan terutamanya bahasa (iaitu, mewakili elemen struktur beberapa bahasa pengaturcaraan). Matlamat utama yang ditetapkan semasa mereka bentuk Handly disenaraikan di bawah:
- Pengenalpastian abstraksi utama kawasan subjek.
- Mengurangkan usaha dan meningkatkan kualiti pelaksanaan model bahasa berasaskan pemegang melalui penggunaan semula kod.
- Menyediakan API peringkat meta bersatu kepada model yang terhasil, membolehkan anda mencipta komponen IDE biasa yang berfungsi dengan model berasaskan pemegang bahasa.
- Fleksibiliti dan skalabiliti.
- Integrasi dengan Xtext (dalam lapisan berasingan).
Untuk menyerlahkan konsep dan protokol biasa, pelaksanaan sedia ada model berasaskan pengendalian bahasa telah dianalisis. Antara muka utama dan pelaksanaan asas yang disediakan oleh Handly ditunjukkan dalam Rajah. 8.
nasi. 8. Antara muka biasa dan pelaksanaan asas elemen Handly
Antara muka IElement mewakili pemegang elemen dan biasa kepada elemen semua model berasaskan Handly. Elemen kelas abstrak melaksanakan mekanisme pemegang/badan umum (Rajah 9).
nasi. 9. Ielemen dan pelaksanaan pemegang/badan generik
Di samping itu, Handly menyediakan mekanisme umum untuk memberitahu tentang perubahan dalam elemen model (Rajah 10). Seperti yang anda lihat, ia secara amnya serupa dengan mekanisme pemberitahuan yang dilaksanakan dalam model sumber dan model Java, dan menggunakan IElementDelta untuk menyediakan perwakilan bersatu maklumat perubahan elemen.
nasi. 10. Antara muka umum dan pelaksanaan asas mekanisme pemberitahuan Handly
Bahagian Handly yang dibincangkan di atas (Rajah 9 dan 10) boleh digunakan untuk mewakili hampir semua model berasaskan pemegang. Untuk mencipta linguistik model, projek ini menawarkan fungsi tambahan - khususnya, antara muka biasa dan pelaksanaan asas untuk elemen struktur teks sumber, yang dipanggil unsur sumber (Gamb. 8). Antara muka ISourceFile mewakili fail sumber, dan ISourceConstruct mewakili elemen dalam fail sumber. Kelas abstrak SourceFile dan SourceConstruct melaksanakan mekanisme umum untuk menyokong kerja dengan fail sumber dan elemennya, contohnya, bekerja dengan penimbal teks, mengikat koordinat elemen dalam teks sumber, menyelaraskan model dengan kandungan semasa penimbal salinan yang berfungsi , dan lain-lain. Melaksanakan mekanisme ini biasanya agak mencabar, dan Handly boleh mengurangkan dengan ketara usaha membangunkan model bahasa berasaskan pemegang dengan menyediakan pelaksanaan asas berkualiti tinggi.
Sebagai tambahan kepada mekanisme teras yang disenaraikan di atas, Handly menyediakan infrastruktur untuk penimbal teks dan syot kilat, sokongan untuk penyepaduan dengan editor kod sumber (termasuk penyepaduan luar kotak dengan editor Xtext), serta beberapa komponen UI biasa yang bekerja dengan editor kod sumber. Model yang mudah digunakan seperti rangka kerja rangka kerja. Untuk menggambarkan keupayaannya, projek ini menyediakan beberapa contoh, termasuk pelaksanaan model Java dalam Handly. (Berbanding dengan pelaksanaan penuh model Java dalam JDT, model ini sengaja dipermudahkan untuk lebih jelas.)
Seperti yang dinyatakan sebelum ini, tumpuan utama semasa reka bentuk awal Handly dan pembangunan seterusnya adalah dan terus berskala dan fleksibiliti.
Pada dasarnya, model berasaskan pemegang berskala dengan baik "mengikut reka bentuk". Sebagai contoh, simpulan bahasa pemegang/badan membolehkan anda mengehadkan jumlah memori yang digunakan oleh model. Tetapi terdapat juga nuansa. Oleh itu, apabila menguji Handly untuk skalabiliti, masalah ditemui dalam pelaksanaan mekanisme pemberitahuan - apabila sejumlah besar elemen ditukar, membina delta mengambil masa terlalu lama. Ternyata masalah yang sama terdapat dalam model Java JDT, dari mana kod yang sepadan pernah disesuaikan. Kami membetulkan pepijat dalam Handly dan menyediakan tampung yang serupa untuk JDT, yang diterima dengan penuh rasa syukur. Ini hanyalah satu contoh yang memperkenalkan Handly ke dalam pelaksanaan model sedia ada berpotensi berguna, kerana dalam kes ini pepijat seperti itu boleh dibetulkan di satu tempat sahaja.
Untuk menjadikan pelaksanaan Handly ke dalam pelaksanaan model sedia ada boleh dilaksanakan secara teknikal, perpustakaan mesti mempunyai fleksibiliti yang ketara. Masalah utama adalah untuk mengekalkan keserasian ke belakang merentas model API. Masalah ini telah diselesaikan dalam dengan mengasingkan dengan jelas API khusus model, yang ditakrifkan dan dikawal sepenuhnya oleh pembangun, daripada API peringkat meta bersatu yang disediakan oleh perpustakaan. Ini bukan sahaja membolehkan secara teknikal untuk melaksanakan Handly ke dalam pelaksanaan sedia ada, tetapi juga memberikan kebebasan yang ketara kepada pembangun model baharu semasa mereka bentuk API.
Fleksibiliti mempunyai aspek lain juga. Sebagai contoh, Handly tidak mengenakan sekatan pada struktur model dan boleh digunakan untuk memodelkan kedua-dua bahasa tujuan am dan khusus domain. Apabila membina struktur fail sumber, Handly tidak menetapkan sebarang bentuk perwakilan AST tertentu dan, pada dasarnya, tidak memerlukan kehadiran AST itu sendiri, dengan itu memastikan keserasian dengan hampir mana-mana mekanisme penghuraian. Akhir sekali, Handly menyokong penyepaduan penuh dengan ruang kerja Eclipse, tetapi juga boleh berfungsi secara langsung dengan sistem fail berkat penyepaduannya dengan (EFS).
Versi terkini keluar pada Disember 2016. Walaupun pada hakikatnya projek itu kini dalam keadaan pengeraman dan API belum lagi diperbaiki, Handly sudah digunakan dalam dua produk komersial besar yang mengambil risiko bertindak sebagai "pengguna awal", dan, saya mesti katakan, jangan menyesal lagi.
Seperti yang dinyatakan di atas, salah satu daripada produk ini ialah 1C:Enterprise Development Tools, di mana Handly digunakan dari awal lagi untuk memodelkan elemen struktur peringkat tinggi seperti 1C:Enterprise bahasa sebagai bahasa pengaturcaraan dan bahasa pertanyaan terbina dalam. . Satu lagi produk kurang diketahui oleh masyarakat umum. ini , persekitaran reka bentuk bersepadu untuk pemproses set arahan khusus aplikasi (ASIP), digunakan dalam syarikat Czech Codasip sendiri dan oleh pelanggannya, termasuk , , , . Codasip telah menggunakan Handly dalam pengeluaran sejak 2015, bermula dengan versi Handly 0.2. Keluaran terbaru Codasip Studio menggunakan versi 0.5, dikeluarkan pada Jun 2016. OndΕej IlΔΓk, yang mengetuai pembangunan IDE di Codasip, sedang berhubung dengan projek itu, memberikan maklum balas penting bagi pihak "pengguna pihak ketiga". Malah dia dapat mencari sedikit masa lapang untuk mengambil bahagian secara langsung dalam pembangunan projek, melaksanakan lapisan UI (~4000 baris kod) untuk salah satu contoh Handly, model Java. Maklumat tangan pertama yang lebih terperinci tentang penggunaan Handly oleh pengguna boleh didapati di halaman projek.
Kami berharap selepas keluaran versi 1.0 dengan jaminan kestabilan API dan projek meninggalkan keadaan pengeraman, Handly akan mempunyai pengguna baharu. Sementara itu, projek itu terus menguji dan menambah baik API, mengeluarkan dua keluaran "utama" setiap tahun - pada bulan Jun (tarikh yang sama dengan keluaran Eclipse serentak) dan Disember, menyediakan jadual yang boleh diramal yang boleh dipercayai oleh pengguna. Kami juga boleh menambah bahawa "kadar pepijat" projek kekal pada tahap rendah secara konsisten dan Handly telah bekerja dengan pasti dalam produk pengguna awal sejak versi pertama. Untuk meneroka lebih lanjut Eclipse Handly, anda boleh gunakan ΠΈ .
Sumber: www.habr.com