Powtórka z narzędzi

Jednym z głównych tematów konferencji Borlanda były narzędzia dla platformy Microsoft .Net, a zwłaszcza niedawno wprowadzony na rynek pakiet Delphi .Net.

Jednym z głównych tematów konferencji Borlanda były narzędzia dla platformy Microsoft .Net, a zwłaszcza niedawno wprowadzony na rynek pakiet Delphi .Net.

Specjalnie zaproszony gość David Intersimone opowiadał o zasadach działania kompilatora dla Delphi generującego kod dla .Net. Drugi, równie ciekawy nurt konferencji był związany z zasadami ''porządnego'' tworzenia aplikacji. Trzeci obszar zagadnień obejmował tworzenie aplikacji w Javie.

Ku łatwej migracji

Borland chce maksymalnie uprościć migrację kodu Delphi na nową platformę i w związku z tym Delphi .Net może na pierwszy rzut oka sprawiać "dziwne" wrażenie.

Większość funkcji i komponentów została jednak przeniesiona wprost z mechanizmów charakterystycznych dla Win32 (i Delphi). Mechanizm threadvars, czyli definiowanie zmiennych globalnych dla danego wątku w .Net jest realizowane za pośrednictwem atrybutów oraz zmiennych globalnych. W przypadku zbiorów w wyniku kompilacji powstaje tablica w .Net.

Innymi słowy, z poziomu Delphi jest to set, a z poziomu innych aplikacji, które np. chcą uzyskać dostęp do danej zmiennej, normalna tablica. Borlandowi nie udało się jednak przenieść wszystkich elementów. Pominięto głównie te, które były wykorzystywane jeszcze w aplikacjach w Turbo Pascal, np. pliki z dostępem za pośrednictwem rekordów czy polecenia określające położenie zmiennych w pamięci.

Zdaniem obecnego na konferencji Borlanda w Warszawie Davida Intersimone'a różnica w wydajności Delphi .Net, czyli - kompilacji do MSIL, a następnie uruchamianie tego MSIL za pośrednictwem kompilatora JIT a "zwykłym" Delphi jest niemal niedostrzegalna. Niemal, bo ze względu na mechanizmy .Net, jak chociażby automatyczny odśmiecacz pamięci, konstrukcje sprawdzone jako wydajne w Delphi niekoniecznie muszą być najbardziej wydajnymi rozwiązaniami na platformie .Net.

Nowe konstrukcje

Delphi .Net pozwala na przeciążanie operatorów. Nie jest to jednak "długa" instrukcja typu switch jak w Kylixie, ale "normalna" klasa o ustalonych nazwach metod odpowiadających danym operatorom. W ten sposób programista może zdefiniować, co będzie ostatecznym efektem wykonania operacji dodawania dwóch klas czy innych typów. Do pakietu wprowadzono także aliasy klas (patrz ramka).

Interfejs użytkownika może być w Delphi .Net tworzony przy użyciu Windows Forms - standardowego pakietu .Net Framework albo VCL .Net - specjalnej wersji VCL przeniesionej na platformę .Net. Dzięki temu migracja starszych aplikacji jest znacznie prostsza. Trzeba jednak wiedzieć, że VCL .Net to nie warstwa "nad" standardowym Windows Forms, ale w pewnym sensie obok. Komunikuje się ona często bezpośrednio z np. kolejką komunikatów Windows, praktycznie z pominięciem warstwy .Net.

Dzięki temu VCL .Net tylko nieznacznie różni się od VCL dla Win32. Ma to jednak również wadę - trudno w Delphi mówić o praktycznym wykorzystaniu Code Access Security (czyli możliwości określania dla fragmentu kodu "żądanych" uprawnień). Aplikacja okienkowa musi mieć "pełne" uprawnienia. Utrudni to np. uruchamianie kodu .Net pobieranego za pośrednictwem przeglądarki.

Niejednorodna przyszłość

W przyszłych wersjach "normalnego" Delphi pojawią się zagnieżdżone typy, atrybuty, możliwość zdefiniowania wielu "odbiorców" zdarzenia oraz przeciążanie operatorów. Zarówno w Delphi .Net, jak i w "zwykłym" Delphi Borland planuje zawrzeć typy ogólne (generics). Są to jednak wstępne rozważania - nie wiadomo, które funkcje pojawią się w najbliższym Delphi dla Win32. Pewne jest tylko to, że w żadnej wersji Delphi nie pojawią się mechanizmy czysto "dotnetowe" w rodzaju własnego odśmiecacza pamięci, języka pośredniego itp.

Warto dodać, że na razie nie są planowane ani integracja VCL .Net z Mono, ani udostępnianie tej biblioteki dla programistów C++ w ramach pakietu C++BuilderX. David Intersimone stwierdził, że obecnie Borland pracuje głównie nad dalszym ułatwianiem migracji z Delphi do Delphi .Net oraz dostosowuje narzędzia do nadchodzącej specyfikacji - .Net 2.0.

Technologia komponentów przenośnych CLX będzie na razie istnieć "obok" nurtu głównych narzędzi Borlanda. Kylix opiera się na bibliotece QT przeznaczonej do tworzenia przenośnego interfejsu użytkownika, tymczasem najnowszy pakiet dla C++ Borlanda - C++BuilderX - wykorzystuje w tym samym celu wxWindows.

David Intersimone uważa, że klienci wolą wxWindows - choćby dlatego, że wprowadza mniej "pośrednich" warstw i oferuje znacznie wygodniejszą licencję.

Borland nadal będzie rozwijać Delphi dla Win32, który generuje kod bezpośrednio dla Windows. Przedstawiciele Borlanda stwierdzili, że skoro na Longhornie będą działać aplikacje Win32 - to warto rozwijać narzędzia na tę platformę.