W tym dodatku są przedstawione różne pomysły związane z możliwymi rozszerzeniami języka TLCC.
W obecnej implementacji języka TLCC tablice są przechowywane w całości w obiekcie, do którego należą. Oznacza to, że podczas serializacji klasy cała tablica jest zapisywana wraz z obiektem. W przypadku dużych tablic jest to jednak niepraktyczne. Lepszym rozwiązaniem byłby podział takiej dużej tablicy i zapisanie jej w kilku sekwencjach (zależnie od jej wielkości). Odczyt określonego fragmentu tablicy byłby wykonywany w momencie odwołania do niego.
Przydatnym rozszerzeniem byłaby możliwość sortowania elementów. Oto
przykład konstrukcji, która sortuje tablicę referencji do obiektów:
class Example
{
string str;
int num;
}
Example[] ex1;
...
Example[] ex2 = sort(ex1;
s1; s2; s1.str < s2.str);
Przedstawiona funkcja sortuje tablicę ex1, wykorzystując
do ustalenia porządku między obiektami wyrażenie podane jako ostatni
argument. Drugi i trzeci parametr tej funkcji to nazwy zmiennych,
poprzez które można się odwoływać do porównywanych obiektów.
Użyteczna byłaby również konstrukcja, pozwalająca usuwać z tablicy
element o określonym indeksie. Jej wykorzystanie mogłoby wyglądać
w sposób następujący:
Example[] ex;
ex[5]!;
Użycie tej konstrukcji powodowałoby automatyczne przesunięcie wszystkich elementów o indeksach większych od podanego, aby zapełnić wolne miejsce powstałe w tablicy.
W języku TLCC można korzystać ze standardowych metod
dostępu do danych, działających na rozproszonych obiektach. Służą
do tego celu referencje oraz różne struktury danych, takie jak tablice,
listy czy słowniki. Jednak w pewnych sytuacjach może się okazać, że
łatwiej byłoby wykonać globalne zapytanie w języku SQL, aby znaleźć
odpowiednią informację. Na klasy zdefiniowane w programie można spojrzeć
jak na tabele, a na obiekty jak na poszczególne wiersze w tych tabelach.
Czasami użyteczna byłaby specjalna instrukcja, która wykona zapytanie
i przekaże tablicę obiektów, będących wynikiem. Oto przykład jej użycia
dla zdefiniowanej wcześniej klasy:
Example[] ex = global_query("select
str, avg(num) from Example group by str");
Oczywiście znacznie prościej jest odwoływać się do pól poszczególnych
obiektów bezpośrednio, niż przy użyciu zapytań. Łatwiej też tworzyć
i usuwać obiekty za pomocą odpowiednich operatorów, niż konstrukcji
języka SQL. Dlatego użycie tej funkcji jest ostatecznością i znajduje
uzasadnienie tylko w przypadku skomplikowanych warunków przy wyszukiwaniu
danych. Natomiast znaczna większość odwołań do danych w typowym serwisie
WWW nie wymaga stosowania złożonych warunków.
Jednakże funkcja global_query() ma pewne zalety w porównaniu z zapytaniami do bazy danych. Poprawność wyrażeń umieszczanych w tej funkcji może być sprawdzona już podczas kompilacji kodu. Ponadto jej użycie jest bardziej zwięzłe niż w przypadku konwencjonalnych zapytań i daje w wyniku tablicę referencji do rzeczywistych obiektów, do których można się następnie odwoływać (np. odczytując lub modyfikując ich pola).
Wynikowy program powinien umożliwiać zmianę modelu danych, z którego korzysta aplikacja, bez utraty dotychczas zgromadzonych informacji. Przykładem jest dodanie atrybutu do klasy lub zdefiniowanie nowej klasy. W przypadku deserializacji obiektu poprzedniej wersji klasy, powinien być on automatycznie dostosowany do nowego modelu (nowy atrybut przyjąłby wartość pustą, czyli w zależności od typu odpowiednio: false, 0, "", null).
Istnieje również możliwość napisania specjalnego programu, którego zadaniem byłaby prezentacja danych zgromadzonych przez aplikację oraz umożliwienie ich bezpośredniej modyfikacji (np. inicjowania nowej struktury danych). Dostęp z zewnątrz (np. z procesu nie wchodzącego w skład samej aplikacji) do obiektów systemu CORBA działającego serwisu jest możliwy, gdyż wystarczy połączyć się z serwerem głównym i wywoływać z niego odpowiednie funkcje.