2.2.2.1 Navnemodellen

I de fleste systemer er der typisk flere forskellige navngivningsordninger i drift samtidig. Et system kan f.eks. anvende ét navngivningsskema til e-mail-postkasse-navne, et andet navngivningsskema til internetværter, et tredje til filer og et fjerde til virtuelle hukommelsesadresser. Når en programfortolker støder på et navn, skal den vide, hvilket navngivningsskema den skal påberåbe sig. Det miljø, der omgiver brugen af navnet, giver normalt nok oplysninger til at identificere navngivningssystemet. I et applikationsprogram ved forfatteren af programmet f.eks., at programmet skal forvente, at filnavne kun fortolkes af filsystemet, og at internetværtsnavne kun fortolkes af en eller anden netværkstjeneste.

Den fortolker, der støder på navnet, kører navnemappingsalgoritmen for det relevante navnemappingsskema. Navnemappingsalgoritmen løser navnet op, hvilket betyder, at den finder og returnerer den tilknyttede værdi (af denne grund kaldes navnemappingsalgoritmen også for en resolver). Navnetilknytningsalgoritmen styres normalt af en ekstra parameter, en såkaldt kontekst. For et givet navngivningsskema kan der være mange forskellige kontekster, og et enkelt navn i navnerummet kan mappe til forskellige værdier, når resolver’en anvender forskellige kontekster. Når en person f.eks. i almindelig tale henviser til navnene “du”, “her” eller “Alice”, afhænger betydningen af hvert af disse navne af den kontekst, hvori personen udtaler dem. På den anden side har nogle navngivningssystemer kun én kontekst. Sådanne navngivningsordninger giver det, der kaldes universelle navnerum, og de har den gode egenskab, at et navn altid har den samme betydning inden for den pågældende navngivningsordning, uanset hvem der bruger det. I USA udgør f.eks. socialsikringsnumre, som identificerer offentlige pensions- og skattekonti, et universelt navnerum. Når der er mere end én kontekst, kan fortolkeren fortælle resolveren, hvilken kontekst den skal bruge, eller resolveren kan bruge en standardkontekst.

Vi kan sammenfatte navnemodellen ved at definere følgende konceptuelle operation på navne:

Når en fortolker støder på et navn i et objekt, finder den først ud af, hvilket navneskema der er tale om, og dermed hvilken version af resolve den skal påberåbe sig. Derefter identificerer den en passende kontekst, løser navnet i denne kontekst og erstatter navnet med den løste værdi, mens den fortsætter fortolkningen. Variablen context fortæller resolve, hvilken kontekst der skal bruges. Denne variabel indeholder et navn, der er kendt som en kontekstreference.

I en processor er registernumre navne. I en simpel processor er både sættet af registernavne og de registre, som disse navne er bundet til, fastlagt på designtidspunktet. I de fleste andre systemer, der anvender navne (herunder registernavneordningen i nogle højtydende processorer), er det muligt at oprette nye bindinger og slette gamle bindinger, at opregne navnerummet for at få en liste over eksisterende bindinger og at sammenligne to navne. Til disse formål definerer vi fire yderligere konceptuelle operationer:

Den første operation ændrer kontekst ved at tilføje en ny binding; statusresultatet rapporterer, om ændringen lykkedes eller ej (den kan mislykkes, hvis det foreslåede navn er i strid med syntaksreglerne for navnerummet). Efter et vellykket kald til bind returnerer resolve den nye værdi for name.* Den anden operation, unbind, fjerner en eksisterende binding fra konteksten, hvor status igen rapporterer succes eller fiasko (måske fordi der ikke var nogen sådan eksisterende binding). Efter et vellykket kald til unbinding returnerer resolve ikke længere denne værdi for name. Operationerne bind og unbind gør det muligt at bruge navne til at skabe forbindelser mellem objekter og ændre disse forbindelser senere. En designer af et objekt kan ved at bruge et navn til at henvise til et komponentobjekt vælge det objekt, som navnet er bundet til, enten på det tidspunkt eller på et senere tidspunkt ved at påkalde bind, og fjerne en binding, der ikke længere er hensigtsmæssig, ved at påkalde unbind, alt sammen uden at ændre det objekt, der bruger navnet. Denne evne til at udskyde og ændre bindinger er et effektivt værktøj, der anvendes i designet af næsten alle systemer. Nogle navngivningsimplementeringer tilbyder en enumerate-operation, som returnerer en liste over alle de navne, der kan opløses i kontekst. Nogle implementeringer af enumerate kan også returnere en liste over alle værdier, der i øjeblikket er bundet i konteksten. Endelig rapporterer compare-operationen (sandt eller falsk), om name1 er det samme som name2 eller ej. Betydningen af “samme” er et interessant spørgsmål, som behandles i afsnit 2.2.5, og det kan kræve, at der leveres yderligere kontekstargumenter.

Differente navngivningsordninger har forskellige regler om entydigheden af navn-til-værdi-tilknytninger. Nogle navngivningssystemer har en regel om, at et navn skal mappe til præcis én værdi i en given kontekst, og at en værdi kun må have ét navn, mens et navn i andre navngivningssystemer kan mappe til flere værdier, eller en værdi kan have flere navne, selv i samme kontekst. En anden form for entydighedsregel er reglen om et navnerum med entydige identifikatorer, som giver et sæt navne, der aldrig vil blive genbrugt i navnerummets levetid, og som, når de først er bundet, altid vil forblive bundet til den samme værdi. Et sådant navn siges at have en stabil binding. Hvis et navnerum med entydige identifikatorer også har den regel, at en værdi kun kan have ét navn, bliver de entydige navne nyttige til at holde styr på objekter over en længere periode, til at sammenligne referencer for at se, om de henviser til det samme objekt, og til koordinering af flere kopier i systemer, hvor objekter replikeres af hensyn til ydeevne eller pålidelighed. F.eks. udgør kundekontonummeret i de fleste faktureringssystemer et unikt identifikationsnavneområde. Kontonummeret vil altid henvise til den samme kundekonto, så længe denne konto eksisterer, på trods af ændringer i kundens adresse, telefonnummer eller endog personlige navn. Hvis en kundes konto slettes, vil denne kundes kontonummer ikke blive genbrugt til en anden kundes konto. Navngivne felter inden for kontoen, som f.eks. den skyldige saldo, kan ændre sig fra tid til anden, men bindingen mellem kundens kontonummer og selve kontoen er stabil.

Navntilknytningsalgoritmen plus en enkelt kontekst tilknytter ikke nødvendigvis alle navne i navnerummet til værdier. Et muligt resultat af udførelsen af resolve kan således være et resultat, der ikke er fundet, hvilket resolve kan meddele opkalderen enten som en reserveret værdi eller som en undtagelse. På den anden side kan et muligt resultat være en liste over værdier, hvis navneskemaet tillader, at et navn kan henføres til flere værdier. I så fald kan operationen unbinding kræve et ekstra argument, der angiver, hvilken værdi der skal ophæves. Endelig giver nogle navngivningsordninger mulighed for omvendt opslag, hvilket betyder, at en kalder kan levere en værdi som et argument til navnemappingsalgoritmen og finde ud af, hvilket navn eller hvilke navne der er bundet til denne værdi.

Figur 2.10 illustrerer navnemodellen, der viser et navnerum, det tilsvarende univers af værdier, en navnemappingsalgoritme og en kontekst, der styrer navnemappingsalgoritmen.

I praksis støder man på tre hyppigt anvendte navnemappingsalgoritmer:

Eksempler fra den virkelige verden på både den generelle navnemodel og implementeringen af table-lookup er der masser af:

Disse eksempler fremhæver også en skelnen mellem “navngivning” og binding. Nogle, men ikke alle kontekster “navngiver” ting i den forstand, at de mapper et navn til et objekt, der almindeligvis opfattes som havende dette navn. Telefonbogen “navngiver” således ikke hverken personer eller telefonlinjer. Et andet sted findes der kontekster, der binder navne til personer, og som binder telefonnumre til bestemte fysiske telefoner. Telefonbogen binder navne på personer til navne på telefoner.