2.2.1 Namnmodellen

I de flesta system är vanligtvis flera olika namngivningsscheman i drift samtidigt. Ett system kan till exempel använda ett namngivningsschema för namn på e-postbrevlådor, ett andra namngivningsschema för Internetvärdar, ett tredje för filer och ett fjärde för virtuella minnesadresser. När en programtolkare möter ett namn måste den veta vilket namngivningsschema den ska använda. Den miljö som omger användningen av namnet ger vanligtvis tillräckligt med information för att identifiera namnsystemet. I ett tillämpningsprogram vet till exempel programförfattaren att programmet bör förvänta sig att filnamn endast tolkas av filsystemet och att Internetvärdsnamn endast tolkas av någon nätverkstjänst.

Tolkaren som möter namnet kör namnmappningsalgoritmen för det lämpliga namngivningsschemat. Namnmappningsalgoritmen löser upp namnet, vilket innebär att den upptäcker och returnerar det associerade värdet (av denna anledning kallas namnmappningsalgoritmen också för en resolver). Algoritmen för namnmappning styrs vanligen av en ytterligare parameter, en så kallad kontext. För ett givet namnschema kan det finnas många olika kontexter, och ett enskilt namn i namnrymden kan mappas till olika värden när resolveraren använder olika kontexter. När en person till exempel i vanlig talspråk hänvisar till namnen “du”, “här” eller “Alice” beror betydelsen av vart och ett av dessa namn på i vilket sammanhang personen uttalar det. Å andra sidan har vissa namngivningssystem endast en kontext. Sådana namngivningsscheman tillhandahåller vad som kallas universella namnrymder, och de har den fina egenskapen att ett namn alltid har samma innebörd inom det namngivningsschemat, oavsett vem som använder det. I Förenta staterna utgör till exempel socialförsäkringsnummer, som identifierar statliga pensions- och skattekonton, ett universellt namnområde. När det finns mer än en kontext kan tolkaren tala om för resolveraren vilken den ska använda eller så kan resolveraren använda en standardkontext.

Vi kan sammanfatta namnmodellen genom att definiera följande konceptuella operation på namn:

När en uttolkare stöter på ett namn i ett objekt, tar den först reda på vilket namnschema som är inblandat och därmed vilken version av resolve den ska åberopa. Den identifierar sedan en lämplig kontext, löser upp namnet i den kontexten och ersätter namnet med det upplösta värdet när den fortsätter tolkningen. Variabeln context talar om för resolve vilken kontext som ska användas. Den variabeln innehåller ett namn som kallas kontextreferens.

I en processor är registernummer namn. I en enkel processor är både uppsättningen registernamn och de register som dessa namn är bundna till fastställda vid konstruktionstillfället. I de flesta andra system som använder namn (inklusive registernamnssystemet i vissa högpresterande processorer) är det möjligt att skapa nya bindningar och radera gamla, räkna upp namnutrymmet för att få en lista över befintliga bindningar och jämföra två namn. För dessa ändamål definierar vi ytterligare fyra konceptuella operationer:

Den första operationen ändrar kontext genom att lägga till en ny bindning; Statusresultatet rapporterar om ändringen lyckades eller inte (den kan misslyckas om det föreslagna namnet bryter mot syntaxreglerna för namnutrymmet). Efter ett lyckat anrop till bind returnerar resolve det nya värdet för name.* Den andra operationen, unbind, tar bort en befintlig bindning från kontexten, där status återigen rapporterar framgång eller misslyckande (kanske för att det inte fanns någon sådan befintlig bindning). Efter ett lyckat anrop av unbind kommer resolve inte längre att återge värdet för name. Operationerna bind och unbind gör det möjligt att använda namn för att skapa kopplingar mellan objekt och ändra dessa kopplingar senare. En konstruktör av ett objekt kan, genom att använda ett namn för att hänvisa till ett komponentobjekt, välja det objekt som namnet är bundet till antingen då eller vid en senare tidpunkt genom att anropa bind, och eliminera en bindning som inte längre är lämplig genom att anropa unbind, allt utan att ändra det objekt som använder namnet. Denna förmåga att fördröja och ändra bindningar är ett kraftfullt verktyg som används vid utformningen av nästan alla system. Vissa namnimplementationer tillhandahåller en enumerate-operation, som returnerar en lista över alla namn som kan lösas upp i sammanhanget. Vissa implementeringar av enumerate kan också returnera en lista över alla värden som för närvarande är bundna i kontexten. Slutligen rapporterar compare-operationen (sant eller falskt) om name1 är samma som name2 eller inte. Innebörden av “samma” är en intressant fråga som tas upp i avsnitt 2.2.5, och det kan kräva att ytterligare kontextargument tillhandahålls.

Olika namngivningssystem har olika regler om entydighet för mappningar av namn till värde. Vissa namngivningssystem har en regel om att ett namn måste mappa till exakt ett värde i ett givet sammanhang och att ett värde bara får ha ett namn, medan i andra namngivningssystem kan ett namn mappa till flera värden, eller ett värde kan ha flera namn, även i samma sammanhang. En annan typ av unikhetsregel är den som gäller för ett namnområde med unika identifierare, som tillhandahåller en uppsättning namn som aldrig kommer att återanvändas under namnområdets livstid och som, när de väl är bundna, alltid kommer att förbli bundna till samma värde. Ett sådant namn sägs ha en stabil bindning. Om ett namnområde för unika identifierare också har regeln att ett värde endast kan ha ett namn, blir de unika namnen användbara för att hålla reda på objekt under en lång tidsperiod, för att jämföra referenser för att se om de avser samma objekt och för att samordna flera kopior i system där objekt replikeras av prestandaskäl eller för att vara tillförlitliga. Exempelvis utgör kundkontonumret i de flesta faktureringssystem ett unikt identifieringsnamnsutrymme. Kontonumret kommer alltid att hänvisa till samma kundkonto så länge kontot existerar, trots ändringar i kundens adress, telefonnummer eller till och med personnamn. Om en kunds konto raderas kommer kundens kontonummer inte att återanvändas för en annan kunds konto. Namngivna fält inom kontot, t.ex. saldot, kan ändras från tid till annan, men bindningen mellan kundkontonumret och själva kontot är stabil.

Algoritmen för namnmappning och en enda kontext mappar inte nödvändigtvis alla namn i namnutrymmet till värden. Ett möjligt resultat av resolve kan därför vara ett resultat som inte hittas, vilket resolve kan meddela anroparen antingen som ett reserverat värde eller som ett undantag. Å andra sidan kan ett möjligt resultat vara en lista över värden om namnschemat tillåter att ett namn mappas till flera värden. I det fallet kan det krävas ytterligare ett argument som anger vilket värde som ska bindas upp. Slutligen tillhandahåller vissa namngivningssystem omvänd sökning, vilket innebär att en anropare kan ange ett värde som ett argument till namnmappningsalgoritmen och ta reda på vilket eller vilka namn som är bundna till det värdet.

Figur 2.10 illustrerar namnmodellen och visar ett namnutrymme, motsvarande universum av värden, en namnmappningsalgoritm och en kontext som kontrollerar namnmappningsalgoritmen.

I praktiken möter man tre ofta använda namnmappningsalgoritmer:

Exempel från den verkliga världen på både den allmänna namnmodellen och implementeringen av tabelluppslag finns i överflöd:

Dessa exempel belyser också en skillnad mellan “namngivning” och bindning. Vissa, men inte alla sammanhang “namnger” saker, i den meningen att de kopplar ett namn till ett objekt som allmänt anses ha det namnet. Telefonkatalogen “namnger” alltså varken människor eller telefonlinjer. Någon annanstans finns det sammanhang som binder namn till människor och som binder telefonnummer till särskilda fysiska telefoner. Telefonkatalogen binder namn på människor till namn på telefoner.