Wiele wskazuje na to, że CA-Clipper 5.2 doczeka się wreszcie następcy. Nowy system będzie nosić nazwę CA-Visual Objects for Windows - słowo Clipper w ogóle się w niej nie pojawi! Czym będzie ten program i jakiego języka będą musieli nauczyć się jego użytkownicy?

Nowy język jest potomkiem Clippera - podobieństwo rodzinne będzie niezaprzeczalne, ale różnicy pokoleń nie da się zignorować. Ponadto kompilator, debugger i edytor nie będą osobno wywoływanymi programami, ale wejdą w skład zintegrowanego środowiska programistycznego działającego pod kontrolą Windows. Tworzone programy też będą przeznaczone do pracy w tym systemie. Nadal będą działać na plikach DBF, ale będą również mogły współpracować z innymi bazami danych za pośrednictwem mechanizmów ODBC (coraz powszechniej stosowana konwencja komunikacji między bazami).

Język obiektowy

Język programowania systemu CA-Visual Objects zawiera pełny zestaw środków programowania obiektowego. Programista nie musi - tak jak w CA-Clipperze 5.2 - ograniczać się do generowania obiektów (zbiorów logicznie powiązanych danych i programów) należących do czterech gotowych klas, ale może zdefiniować swoje klasy. Nowe klasy mogą być definiowane na podstawie już istniejących, gdyż CA-Visual Objects dostarcza środków językowych umożliwiających dziedziczenie przez nową klasę metod (podprogramów związanych z obiektami) i zmiennych wyspecyfikowanych w klasie zdefiniowanej wcześniej.

Nowy język zawiera oryginalne rozwiązanie, wzmacniające ochronę wewnętrznej struktury obiektów i pozwalające ukryć techniczne szczegóły ich działania. Są to specjalne identyfikatory związane z obiektem, określane jako zmienne wirtualne. Pod względem składniowym są one nieodróżnialne od nazw pól danych, jednak ich użycie w instrukcji podstawienia automatycznie uruchamia dowiązane do nich podprogramy.

Interfejs z prefabrykatów

CA-Visual Objects służy do pisania programów dla Windows. Pojawiają się tu dwa problemy: tworzenie złożonego graficznego interfejsu użytkownika (GUI) z zachowaniem konwencji Windows oraz wykonanie sterowane zdarzeniami (event driven), tzn. uruchamianie odpowiednich podprogramów w momentach uzależnionych od działań użytkownika (przesunięcie kursora, wciśnięcie przycisku itp.) a nie od układu rozkazów w programie. Programowanie obiektowe wyjątkowo dobrze nadaje się do rozwiązywania tych problemów.

System jest wyposażony w duży wybór gotowych klas do obsługi interfejsu użytkowego (GUI). Zawiera struktury danych i podprogramy niezbędne do opisu współpracy z myszą, realizacji techniki drag-and-drop oraz koordynacji i "animacji" okien dialogowych, menus, browserów ("przeglądarek" - tabel podobnych do arkusza kalkulacyjnego), formatek i innych obiektów ekranowych.

Obiekty z których można budować programy sterowane zdarzeniami są zawarte w bibliotece CA-Common View. Zawiera ona także obsługę komunikatów o zdarzeniach generowanych przez użytkownika i Windows.

Nadmiar szczęścia

Dziedziczenie to mechanizm pozwalający na wielokrotne wykorzystanie raz zdefiniowanych algorytmów i struktur danych (code reuse). Przypuśćmy np. że działanie i strukturę prostego okienka edycji tekstu opisano w definicji klasy Edytor. Wyobraźmy sobie, że chcemy stworzyć edytor do pisania od prawej do lewej (eksport do Arabii Saudyjskiej?). W tym celu tworzymy definicję nowej klasy pochodnej od klasy Edytor, powiedzmy EdytorOdwracający. W definicji klasy pochodnej musimy opisać tylko algorytm rozmieszczania kolejnych wprowadzanych liter. Kompilator zakłada, że pozostałe akcje, których opis pominięto, są dziedziczone, tzn. mają przebiegać zgodnie z algorytmami opisanymi w definicji klasy podstawowej - w tym wypadku klasy Edytor.

Dziedziczenie pozwala uniknąć powielania kodu. Pamiętajmy jednak, że program użytkowy średniej wielkości może zawierać kilkadziesiąt definicji klas. Dlatego ważne jest, aby znalezienie fragmentu kodu było łatwiejsze niż jego powtórne napisanie, aby programista miał kontrolę nad zależnościami łączącymi poszczególne fragmenty programu i wreszcie - aby panował nad zjawiskiem propagacji zmian, w efekcie którego np. modyfikacja wprowadzona w klasie Edytor rzutuje na działanie klasy EdytorOdwracający, a także na działanie wszystkich innych klas pochodnych.

Kolejne wyzwanie stanowią składniki interfejsu graficznego - wewnętrznie złożone "zlepki" kodu, zmiennych i elementów graficznych, zwykle uzależnione od struktury i zawartości obsługiwanej bazy danych, wzajemnie powiązane siecią zmiennych relacji funkcjonalnych, geometrycznych i logicznych. Ich złożoność bardzo utrudnia utrzymanie stałej kontroli nad strukturą większych programów. Wydruki, notatki i edytor tekstowy już nie wystarczają.

Edytory i browsery

Aby umożliwić utrzymanie kontroli nad kodem programów o narastającej złożoności, producent wyposażył system CA-Visual Objects w graficzne środowisko wspomagania programisty (IDE) oraz w system określany jako składnica lub repozytorium (repository).

Środowisko programisty zawiera - obok kompilatora i debuggera - edytory i tzw. browsery. Browser jest to interakcyjne narzędzie, zwykle w postaci tabeli lub drzewa napisów, umożliwiające użytkownikowi przegląd dużych zbiorów jakichkolwiek elementów opatrzonych nazwami. Norton Commander jest przykładem prostego browsera do przeglądu plików i katalogów. Browsery w CA-Visual Objects służą do przeglądania aplikacji i ich składników.

Edytory środowiska CA-Visual Objects umożliwiają nie tylko działania na tekstach źródłowych, ale także graficzne opracowywanie okien, menu i formatek specyfikacji pól (kolumn) baz danych. W skład środowiska wchodzi też interakcyjny graficzny generator raportów CA-RET. System umie przetworzyć graficzne i tabelaryczne projekty elementów interfejsu utworzone pod kontrolą edytorów na fragmenty tekstu źródłowego, które przy użyciu edytora tekstowego podlegają dalszej obróbce.

CA-Visual Objects jest wyposażony w browsery zapewniające dostęp do aplikacji, klas, modułów i tzw. jednostek (entities), tzn. okien, menu, raportów, definicji zmiennych, struktur (rozumianych podobnie jak w języku C), funkcji oraz specyfikacje pól w bazach danych. Browser klas wyświetla ich nazwy w postaci drzewa, którego struktura odpowiada hierarchii klas podstawowych i pochodnych. Kliknięcie myszką na powierzchni nazwy w oknie browsera powoduje wyświetlenie wskazanego elementu pod kontrolą odpowiedniego edytora.

Repozytorium

Repozytorium (albo inaczej składnica) jest to podsystem środowiska IDE współpracujący z jego interfejsem graficznym oraz wyposażony w wewnętrzną bazę danych, w której są przechowywane wszystkie elementy wyświetlane przez browsery i edytory. Jej zawartość jest dostępna tylko za ich pośrednictwem.

Repozytorium można opisać jako zautomatyzowany i rozbudowany odpowiednik tzw. make-files (znanych m.in. z C i Clippera) oraz obsługujących je programów narzędziowych, gdyż przechowuje ono informacje o powiązaniach między składowymi programów i jest odpowiedzialne za nadzorowanie i aktualizację tych informacji oraz - częściowo - za spójność definicji przechowywanych składników.

Repozytorium współpracuje z kompilatorem zlecając mu przy zmianie składnika programu - np. deklaracji zmiennej - powtórną kompilację wszystkich fragmentów zależnych od zmienionego składnika - np. wszystkich podprogramów wykorzystujących przedefiniowaną zmienną. Wspomniany już podział aplikacji na małe jednostki (entities) umożliwia bardzo oszczędne działanie repozytorium, określone przez zasadę minimalnej rekompilacji: powtórna kompilacja dotyczy tylko tych jednostek, które zawierają odwołanie do zmienionego składnika zwykle są one mniejsze od aplikacji, a nawet modułu.

SQL, serwery, drajwery ...

Visual Objects standardowo działa na plikach o tradycyjnym formacie clipperowym (DBF z indeksami NTX). Dostęp do innych baz jest możliwy dzięki wbudowanym mechanizmom wykorzystującym pośrednictwo ODBC (Open Data Base Connectivity) oraz tzw. wymiennym drajwerom baz danych - RDD (Replaceable Database Drivers). Obok standardowego drajwera "rozumiejącego" pliki indeksowe NTX producent ma dostarczać (w cenie pakietu przynajmniej dwa dodatkowe: do indeksów NDX (dBase III) i MDX (dBase IV).

RDD są to biblioteki DLL utworzone przez CA bądź innych producentów, zawierające funkcje najniższego poziomu obsługi baz danych. Wszystkie instrukcje manipulacji danymi są tłumaczone na ich wywołania, dlatego funkcje te muszą być opatrzone nazwami zdefiniowanymi przez CA i rozumianymi przez CA-Visual Objects. Obok funkcji każdy RDD powinien zawierać tablicę z ich adresami. Biblioteki RDD mogą tworzyć hierarchię - jeśli w tablicy na pozycji przypisanej konkretnej funkcji znajduje się adres zerowy, to system szuka adresu na tej samej pozycji w drajwerze kolejnego poziomu.

Zasady działania baz relacyjnych (SQL) są inne niż baz Clippera, dBase itp., określanych nieraz jako nawigacyjne. Aby ułatwić programistom czytelny zapis operacji na bazach obu typów, Computer Associates wyposażyła swój produkt w gotowe klasy obiektowe nazywane serwerami danych (data servers). Obiekty tych klas współpracują z drajwerami RDD. Wywołania metod realizowanych przez serwery klasy SQLSelect mają postać formuł języka SQL, a metody klasy DBServer są bardzo zbliżone do funkcji Clippera 5.2.

To wszystko może brzmieć niepokojąco dla użytkowników Clippera przyzwyczajonych do korzystania z tradycyjnych konstrukcji tego języka, pochodzących z wersji Summer 87 albo nawet z dBase'a III. Czy będą mogli korzystać z CA-Visual Objects nie zmieniając z dnia na dzień swoich przyzwyczajeń? I czy będą mogli w miarę szybko przenieść stare aplikacje pod nowy system? Raczej tak.

... a co z normalnym SAY-GET?

Mimo unowocześnienia języka tradycyjne konstrukcje nie będą z niego usunięte. Komendy pamiętające jeszcze czasy dBase'a będą, podobnie jak w wersji 5.2, dostępne dzięki plikowi nagłówkowemu z definicjami przeznaczonymi dla preprocesora. Możliwe będzie programowanie hybrydowe, łączące SQL z funkcjami Clippera 5.2 lub z ich wersjami obiektowymi.

Kolejna dobra (?) wiadomość: programowanie z użyciem tradycyjnych Xbase'owych konstrukcji składniowych (np. @...SAY...GET) jest możliwe dzięki obiektom emulującym terminal alfanumeryczny. Obiekty te są zaszyte na tyle głęboko (konkretnie: poniżej warstwy definicji preprocesora), że można z nich korzystać nie wiedząc o ich istnieniu.

Obok obiektów i SQL pojawią się dwie kolejne nowości: zmienne o typie ustalanym raz na zawsze w momencie deklaracji i struktury (zbliżone do struktur w języku C), czyli zmienne złożone z pól o różnej wielkości opatrzonych nazwami, rezydujące w pamięci operacyjnej. Ci programiści, którzy nie przepadają za deklarowaniem zmiennych i ścisłą kontrolą typów przez kompilator mogą jednak programować "po staremu".

Nowy kompilator ma działać znacznie szybciej od starego. Zawdzięcza to zupełnie innej (chociaż wcale nie nowatorskiej) konstrukcji. Instrukcje będą tłumaczone bezpośrednio na kod maszynowy. Jeszcze w wersji 5.2 używano translatora generującego kod pośredni, wymagający interpretacji w trakcie wykonania.