NIMITILOJEN KÄYTÖSTÄ DYALOG-SOVELLUSKEHITYKSESSÄ

Jukka Vaijärvi, Dinosoft Oy

 

Nimitilat (engl. namespace) ovat eräänlaisia APL-työtilan sisäisiä "minityötiloja", jotka voivat sisältää samoja APL-objekteja kuten normaalitkin työtilat: muuttujia, funktioita, operaattoreita ja toisia nimitiloja. Windows-Dyalogissa graafinen käyttöliittymä onkin toteutettu sisäkkäisten nimitilojen hierarkiana, esimerkiksi ikkunassa oleva painonappi on toteutettu ikkuna-nimitilan alinimitilana, jonka tyyppinä tässä tapauksessa on ‘Button’. Kaikille nimitiloille on määritelty oma tyyppinsä, puhtailla nimitiloilla (jotka eivät ole graafisia, ns. GUI-objekteja) tyyppi on "Namespace". Puhtaalla nimitilalla ja GUI-objektilla (esim. ikkunalla) on paljon yhteistä, GUI-objektiin voidaan säilöä APL-funktioita ja muuttujia kuten nimitilaankin ja siitä voidaan tarvittaessa tehdä erityinen muuttujapaketti []OR-funktiolla. Mikäli halutaan, että GUI-hierarkiaan säilötty koodi ja muuttujat jäävät olemaan lomakkeen sulkemisenkin jälkeen, voidaan "KeepOnClose" -ominaisuus asettaa arvoon 1 (tosi). Tämä aiheuttaa sen että GUI-objektin saadessa "Close" -eventin esim. lomakkeen sulkemisen yhteydessä, itse lomake häviää näytöltä, mutta se muuttuu "puhtaaksi" nimitilaksi, jolloin sen sisältämä APL-koodi ja muuttujat ovat edelleen sovelluksen käytettävissä. Muussa tapauksessa lomake tuhoutuu sisältöineen, aivan kuin se olisi hävitetty []EX -funktiolla.

 

Nimitilojen luominen onnistuu joko )ns -systeemikomennolla tai []NS tai []WC -systeemifunktioilla, joista jälkimmäistä käytetään GUI-objektien luomiseen. Useimmiten uusi GUI-objekti tai nimitila syntyy senhetkisen nimitilan alinimitilaksi, ellei luontiparametrina anneta tarkkaa polkumäärettä. Nimitiloissa oleviin objekteihin viitattaessa joudutaan pääsääntöisesti käyttämään polkumäärettä (esim. #.LOMAKE.BTN1.Funktio). Vaihtoehtoinen tapa funktiokutsuille on muodostaa []PATH-systeemimuuttujan avulla listoja nimitiloista, joista kutsuttua funktiota etsitään. Nimitilat voi ymmärtää myös Dos-hakemistojärjestelmän analogiana: nimitilaa vastaa Dos-hakemisto ja []PATH-muuttujaa PATH-määre. []PATH :ssa voi käyttää myös ­ -primitiiviä, joka tulkitaan ohjeena etsiä senhetkisestä nimitilasta, sen vanhemmasta jne. aina sovelluksen (#) tai session []SE nimitilajuureen saakka. Mikäli haluaa asettaa jonkin nimitila funktion []PATH -mekanismin haun ulkopuolelle, sen voi tehdä []EXPORT -funktiolla, jolloin funktion export-ominaisuus asetetaan nollaksi. Tällöin funktiosta tulee []PATH -mekanismin kannalta näkymätön. []PATH :iin liittyy myös systeemin ylläpitämä pino kutsunimitiloista []NSI, joka rakenteeltaan muistuttaa funktiokutsupinoa []SI. Tätä pinoa tutkimalla []PATH -mekanismin käynnistämä funktio voi päätellä sen, mistä nimitilasta alkuperäinen kutsu tapahtui ja mahdollisesti siirtää []CS -funktiolla suorituksensa kyseiseen nimitilaan.

 

Mihin nimitiloja kannattaa sitten käyttää? Eräs näppärä tapa liittää sovellukseen muista APL-ympäristöistä tuotua koodia on muodostaa oma nimitila Dyalogin kannalta "vieraalle" koodille, jolloin vieraan ympäristön emulointi onnistuu kohtalaisen hyvin nimitilan lokaaleilla []ML, []IO yms. systeemimuuttujilla. Emulointi voidaan näin rajata paikallisesti yhteen helposti hallittavaan nimitilaan, eikä muuhun koodiin tarvitse koskea. Nimitiloja voidaan käyttää myös sovelluksen rakenteelliseen jäsentelyyn, esimerkiksi tiedostojen IO-funktiota tai tietokantafunktiot voitaisiin eristää omaan nimitilaansa ympäristöstään itsenäiseksi paketiksi.

 

Tällainen paketti voitaisiin helposti istuttaa kaikkiin niihin sovelluksiin, jotka tarvitsisivat kyseisen paketin palveluita. Kokonaisen nimitilan siirto onnistuu helposti )COPY-komennolla. Lähiverkkoa hyödyntävä organisaatio voisi lisäksi siirtää yleiskäyttöiset paketit omalle tiedostopalvelimelleen, jolloin niiden ylläpito tapahtuisi keskitetysti yhdessä paikassa. Tälläisessä arkkitehtuurissa APL-sovellus voisi käynnistyessään sisältää minimaalisen määrän koodia, tarvittavat yleiskäyttöiset pakettinimitilat voitaisiin noutaa palvelimelta siinä vaiheessa kun sovellus niitä tarvitsisi. Nimitilan poisto työmuistista on sekin helppoa []EX-funktiolla. Sovelluksessa voisi olla valmiit tietynnimisten nimitilojen tuhoamislistat siltä varalta että työmuistia haluttaisiin ajonaikaisesti vapauttaa heittämällä sillä hetkellä tarpeettomat nimitilat yli laidan.

 

Nimitiloja on myös mahdollista käyttää ajonaikaiseen suurten tietomäärien varastointiin. Parhaillaan työn alla oleva moniuloitteisia sääntiöitä käsittelevä laskentaohjelmisto Saurus säilyttää kutakin muistiin muodostettua taulukkoa ja sen lisämuuttujia omassa nimitilassaan. Kaikille taulukko-nimitiloille on niillekin oma säilytysnimitilansa, joka näkyy työtilajuureen #.DAT -nimisenä. Tällä menettelyllä saavutetaan se etu, että taulukoita käsittelevistä funktioista voidaan tehdä luonteeltaan niin yleiskäyttöisiä, että ne ottavat selvää, mikä taulukko kulloinkin on aktiivisena, ja suorittavat toimenpiteensä tämän aktiivisen nimitilan sisältämille sääntiöille, joko viittaamalla niihin polun avulla (esim. #.DAT.D5.MMAT) tai siirtymällä []CS -systeemikomennolla aktiiviseen nimitilaan ja viittaamalla sääntiöön suoraan, koska se ajonaikaisesti on käytännössä samassa nimitilassa suoritettavan funktion kanssa. Ohjelman suoritus on myös mahdollista keskeyttää menusta suoraan aktiivisen taulukon nimitilaan, jolloin käyttäjällä on käytettävissään koko APL:n ilmaisuvoima muokatessaan taulukkoa ikäänkuin se olisi normaali globaali sääntiö työtilassa.

 

Siirrettyä suoritusta voi hyödyntää myös monien GUI-objektien kanssa, esim. MDI-ikkunan dokumentti-ikkunat voivat kaikki sisältää omia sisäisiä muuttujiaan, mutta käyttää samoja event-käsittelyfunktioita (jotka nekin voivat sijaita omassa nimitilassaan). Dyalogissa event-viestin rakenne on sellainen, että ensimmäisenä alkiona event-vektorissa on aina eventin saaneen objektin nimi. Eventin käsittelevä funktio voi ottaa viestistä tämän nimen talteen ja siirtyä []CS -funktiolla kyseiseen objektiin tekemään jotain sen muuttujille tai mikäli muuttujat sijaitsevatkin jossain sen isä-objektissa, objektin polkuviittauksesta voi välipisteitä parseroiden pudottaa niin monta loppunimeä pois että päästään halutulle tasolle GUI-hierarkiassa ja halutut muuttujat näkyvät siirretyssä suorituksessa käsittelevälle funktiolle. Toinen tapa selvittää kohdenimitila on tutkia funktiokutsujen nimitilapinoa []NSI:ta.

 

Nimitilaviittausten erittelyä varten kannattaa rakentaa oma työkalufunktionsa, jonka voi sijoittaa sellaiseen nimitilaan, jossa se on []PATH -mekanismin saavutettaessa. Funktiolle voitaisiin antaa parametrina esim. nimitilan koko polku sekä montako nimitasoa halutaan alusta tai lopusta ottaa tai pudottaa pois. Tällaisen työkalun ei tarvitse toimiakseen siirtyä mihinkään toiseen nimitilaan, vaan tulos voidaan välittää kutsuvalle funktiolle normaalina paluuarvona. Sama pätee muihinkin APL-yhteisölle tuttujien idiomityyppisten työkalujen käyttöön (DTb, NL jne.). Työkalufunktiotkin voidaan jakaa myös sovelluksen tarvitsemiin ja sovelluskehittäjän tarvitsemiin työkaluihin. Varsinaiset ohjelmointityökalut, joiden ei haluta jäävän itse sovellukseen, kannattaa sijoittaa itse session nimitilaan (joka pitää muistaa myös tallettaa omasta menustaan, mikäli sitä aikoo jatkossa hyödyntää). Dyalogin User Guidessa on lisätietoja siitä, miten sessiota pystyy muokkaamaan mieleisekseen. Kehitysympäristön vapaa muokattavuus onkin eräs Dyalog APL:n vahvuuksista, jolla sovellusohjelmoija voi parantaa työnsä tuottavuutta.

 

Olio-ohjelmoinnin näkökulmasta nimitila voitaan käsittää myös tietyn oliotyypin luokkamäärittelynä, joka sisältäisi ainakin olion rakennus-, alustus- ja vapautusfunktiot muine luokkakohtaisine metodeineen. Dyalog APL:n []PATH -mekanismi ei toimi vielä sillä kattavuudella, että Dyalogia voitaisiin pitää aitona olio-ohjelmointiympäristönä, esimerkiksi tiettyyn nimitilaan ohjautuva eventin takaisinkutsu ei aiheuta []PATH :in mukaista etsintää määritellyistä nimitiloista, vaan seurauksena on VALUE ERROR, mikäli funktiota ei löydykään juuri tuosta nimitilasta. Sama pätee funktion suorittamiseen session komentoriviltä. Tämä harmillinen puute aiheuttaa sen, ettei tietystä nimitilasta voida näppärästi periyttää jälkeläistä, joka jakaisi sen metodit omien metodiensa lisäksi. Nimitilojen ja []PATH -mekanismin käyttöönoton voi kuitenkin tulkita askeleeksi kohti välinettä, joka yhdistäisi APL:n tiiviin esitystavan ja olioympäristön ylläpidon helppouden. Tätä odotellessa kannattanee jo tutustua olio-ohjelmoinnin peruskäsitteisiin ja terminologiaan jostain alan perusteoksesta, eräät olio-ohjelmoinnin hyvistä piirteistä kun tuntuvat olevan APL-sovellusohjelmoijan ulottuvilla jo nykyisilläkin välineillä.