Podczas prezentacji oprócz naprawdę fajnego demka z szachami wyjaśniona została także architektura samego projektu. Przyznam że bardzo podoba mi się zastosowanie Google Guice jako sposobu na kastomizację generatów. Łączenie kodu generowanego z ręcznie pisanym zawsze stanowiło duży problem w projektach o większym stopniu złożoności niezależnie od zastosowanego podejścia. Zwykle kończyło się to albo dziesiątkami metod 'generated NOT' albo było skrajnie niewygodne jak modyfikacje w 'GMFGen' lub 'zastępowanie szablonów'. Szczególnie problem widoczny jest właśnie w przypadku biblioteki GMF która generuje naprawdę złożony kod który należy w dużej mierze zmodyfikować. Zastosowanie technologii Guice pozwala na znaczne rozluźnienie relacji pomiędzy poszczególnymi fragmentami budowanego edytora co znacznie upraszcza proces jego kastomizacji.
Bardzo ciekawy jest także dalszy kierunek rozwoju. Tematem przewodnim jest budowanie złożonych projektów opartych o wiele współpracujących modeli czyli koncepcja budowy indeksu modeli (instancji) w ramach środowiska. Rejestr modeli to jedno z pierwszych zadań jakie musi wykonać każdy projektant tworzący IDE. Ponieważ użytkownicy będą tworzyli dziesiątki lub setki instancji modeli w ramach projektu indeksowanie jest konieczne by wzajemnie się one widziały i możliwe były akcje typu wyszukanie czy refaktoring. Ustandaryzowanie tego typu mechanizmów może być kamieniem milowym w kierunku uniwersalnych mechanizmów refaktoringu (połączenie koncepcji index + compare)
Drugim tematem jest budowa tzw. języka bazowego dla reprezentacji wyrażeń. W każdym środowisku tworzymy lub wykorzystujemy jakiś istniejący język wyrażeń by wiązać poszczególne elementy modelu, reprezentować warunki etc. Czy jest to popularny XPATH, kolejna mutacja OCL czy cokolwiek innego mocno zależy to od wymagań tworzonego środowiska. Uproszczenie tego tematu wydaje się być atrakcyjne ale nie jestem pewien czy jest ono konieczne. Mamy już kilka modeli wyrażeń a pomimo tego każdy i tak tworzy własny by najlepiej odpowiadał potrzebom danego systemu. Nie do końca jestem przekonany czy powstanie kolejnego języka (bazowego?) cokolwiek wniesie do tematu. Przyznam że bardziej wolałbym gdyby połączono i dopracowano istniejące języki tak by powstała jedna składnia OCL’a, pojedyncza wersja XPAND’a etc. Możliwe jednak że źle rozumiem kierunek tego podprojektu. Czas więc poszukać dodatkowych informacji co i jak.
XText bez wątpienia wprowadza do środowiska Eclipse co najmniej tak dużo nowych możliwości jak kilka lat temu zrobił to GMF. Gdy tylko skończę czytać kupioną niedawno książkę o GMF biorę się za naukę. Mam nadzieję że analiza tego projektu pozwoli mi rozwiązać także problemy w moim własnym projekcie (koncepcja zastosowania Guice etc.)
4 komentarze:
Google Guice w Xtext jest raczej przykładem dobrej architektury (wykorzystania IoC) niż "kastomizacji generatorów".
W .Net rozwiązali sporo problemów z generowaniem kodu przez wprowadzenie partial class i partial method. Spring Roo z kolei korzysta z AspectJ, tworząc analogiczne rozwiązanie(korzystają z Inter-type declarations, wychodzi brzydziej, ale z dużymi możliwościami).
Poza tym chyba pora, by więcej osób zaczęło mówić, że z GMF jest coś nie tak ;)
Nie mam w GMF doświadczenia, ale parafrazując motto Xtext, tam proste rzeczy nie są proste, a trudne są jeszcze trudniejsze. To że można proste rzeczy robić prosto (nawet w graficznych dsl pokazuje) GEMS i Microsoft DSL Toolkit.
Jako, że już Xtext 0.8 będzie najpewniej pozwalał dziedziczyć po wielu gramatykach, to język bazowy ma swoje zalety, wystarczy (przynajmniej w teorii) dodać gramatykę do arytmetyki, by w swoim języku wspierać arytmetykę (albo logikę, albo jedno i drugie...). Trzeba by pewnie jeszcze podpiąć się pod typy w arytmetyce, ale to wydaje mi się proste i nie jest potrzebne jeśli byśmy korzystali z typów wbudowanych.
Dalej mając język bechawioralny w np. w modelu encji, albo przepływie, nie trzeba dodawać logiki ręcznie pisanej w Java, można ją zawrzeć w jednym modelu i generować potencjalnie 100%. Można też zaciągnąć tu Guice i w modelu zapisać tylko domyślną implementację, a w Java podpinać inne w razie potrzeby.
Co wyjdzie z języka bazowego jeszcze nie wiadomo, tak czy inaczej bardzo jestem nim zainteresowany.
Pozdrawiam,
Krzysztof Kowalczyk
Świadomie napisałem że podoba mi się wykorzystanie Guice jako sposobu na kastomizację generatów (kodu generowanego edytora). Wybór konkretnego sposobu kastomizacji budowanego edytora jest oczywiście decyzją architektoniczną. Zastosowanie mechanizmu IOC w przypadku aplikacji webowych jest standardem od wielu lat, jednak w przypadku generacji kodu GUI jest odświeżającą nowością.
Co do języka bazowego nie do końca podzielam twój optymizm. Idea DSL polega głównie na dopasowaniu rozwiązania do problemu.
Osobiście jako swojego "języka bazowego" od blisko pięciu lat używam notacji XPATH w różnych projektach. Model ten wykorzystywałem z wieloma strukturami opisu danych, komponowałem go także z różnymi modelami klienckimi (nadając mu różne znaczenie). Model taki zarówno interpretowałem w jednym projektów jak generowałem z niego pochodne wyrażenia czy odpowiadający logice pełny kod w języku Java w innym.
Daleki jednak jestem od twierdzenia że jakiś model można nazwać modelem bazowym dla każdego zastosowania. Najważniejsze jest dobre dopasowanie do problemu. W przypadku uniwersalnej notacji obawiam się że skończymy z modelem w stylu diagramów UML’a które starają się być tak bardzo uniwersalne że staje się zupełnie bezużyteczne.
Całe szczęście dependency injection jest wykorzystywane w e4 :)
"Język bazowy" (nawet jeśli to będzie jeden język) nie ma być podstawą po której dziedziczą inne języki. Raczej bardziej będzie na zasadzie "mixins", czyli dorzucamy fragment gdy chcemy mieć jakieś nowe możliwości. A jak to będzie wyglądać to zdaje się, sami twórcy jeszcze nie wiedzą. Jak sam powiedziałeś xpath ma tendencje często się sprawdzać do nawigacji. W samym xpath wykorzystuje arytmetykę. Budowa Xtext teoretycznie pozwala na łatwe rozszerzenie języka syntaktycznie. Trochę trudniej ale semantyka też w pewnej części może być zdefiniowana, z możliwością podmiany.
Nie będę się upierał przy tym, jak przydatne to się okaże, niemniej chętnie zobaczę co z tego wyniknie.
Pozdrawiam,
Krzysztof Kowalczyk
Baccarat in Ireland | Legal betting in Ireland | Viking.com
In addition to choegocasino the regular UK betting market, the online gambling site offers a range of baccarat games for all new players 메리트카지노 and players to worrione enjoy.
Prześlij komentarz