trzewiczek info



23.09.2010 kod:blog
ChucK a statyczne referencje
Niestety ChucK jest wciąż we wczesnej fazie rozwoju, przez co wiele prostych rzeczy należy robić “na skróty”. Przykładem są statyczne pola klas, które nie są typami podstawowymi. W kwestii typów ChucK wzorowany jest na Javie – wszystko, co nie jest typem podstawowym (int, float, char) jest referencją do obiektu. Stąd mamy prosty problem – statyczny napis wewnątrz klasy.

Typ string jest referencją do obiektu. Wydawałoby się, że można w takim razie zainicjować rzecz tak:

class Utility
{
    "My error message" @=> static string error;
}

Niestety pojawiają się dwa błędy:
1. Nie można inicjalizować statycznych referencji wewnątrz klasy. Trzeba zrobić to z zewnątrz.
2. Nie wiedzieć czemu ChucK (przynajminiej na 32-bitowej Fedorze) nie pozwala na deklarację statycznej referencji do napisu.
Jakie mamy wyjście? Wykorzystanie zasięgu widoczności klas:

public class Utility
{
    static Error @ e;
    fun static string error()
    {
        return e.error;
    }
}

class Error
{
    "Error message" @=> string error;
}

new Error @=> Utility.e;
<<< Utility.error() >>>;

Trochę to pogmatwane, ale daje radę. Klasa Utility pozostaje publiczna i statyczna (choć nie ma bezpośrednio takiego konceptu w ChucKu) oraz nasza implementacja nie łamie zasad bezpieczeństwa – klasa Error widoczna jest jedynie w zasięgu tego pliku źródłowego, więc w pewnym sensie możmy ją uznać za prywatną.

Dobra. To były referencje więc nie mogło być łatwo. Co jednak z tym, że statyczne pola typów podstawowych nie są inicjowane? To już jest jazda:

public class Utility
{
    100 => static int x;
}

<<< Utility.x >>>;

W konsoli zobaczymy śliczne 0!!! Metoda na ominięcie tego jest taka, jak powyżej – inicjować poniżej kodu klasy!

public class Utility
{
    static int x;
}

100 => Utility.x;

Teraz możemy odwoływać się do zmiennej x zupełnie bezpiecznie z dowolnego miejsca w programie. Proste, nie? ;)
N E W S