Loading...
Please wait, while we are loading the content...
Similar Documents
Vurdering av generiske typer i programmeringsspråket Java.
| Content Provider | Semantic Scholar |
|---|---|
| Author | Rognerud, Endre Meckelborg |
| Copyright Year | 2001 |
| Abstract | class LessAndEqual { abstract boolean lessThan(This other); abstract boolean equal(This other); } class Relations extends LessAndEqual { typedef C as LessAndEqual; // inneholder de nye metodene basert på de eksisterende ... } Problemet oppstår når man i et brukerprogram ønsker å opprette en konkret klasse, som skal være en subklasse til LessAndEqual samtidig som den skal være en superklasse til Relations. Det er her umulig å definere klassen Relations slik at den blir en subklasse til en konkret brukerklasse som ikke vil være kjent med kompilering av biblioteket. Dermed virker ikke den innfallsvinkelen. Likevel finnes det en mulighet som gjør at man kanskje kommer et skritt nærmere en løsning. Java støtter bruk av indre klasser (klasser som innehol3.1 Virtuelle typer, Thorup 31 der andre klasser). Ved å plassere klassene LessAndEqual og Relations på biblioteket inne i en omkringliggende klasse RelationsContainer, åpner det seg en mulighet som avhenger av om man i Thorups forslag tillater såkalte ”virtuelle superklasser” (må ikke blandes sammen med en lignende betegnelse i C++). Vi kunne da legge følgende på biblioteket: class RelationsContainer { typedef C as LessAndEqual; abstract class LessAndEqual { // som definert over. ... }class LessAndEqual { // som definert over. ... } // C blir her en virtuell superklasse for ”Relations”. class Relations extends C { // som definert over. ... } } I brukerprogrammet må man også opprette en klasse som inneholder de andre klassene man behøver. Denne klassen, som her er kalt AdvancedRelationsContainer, skal være en subklasse av RelationsContainer. Brukerprogrammet vil da være: class AdvancedRelationsContainer extends RelationsContainer { typedef C as SimpleRelations; class SimpleRelations extends LessAndEqual { // inneholder de faktiske definisjonene av // “lessThan” og “equal”. ... } class AdvancedRelations extends Relations { } } Eksempelet over kan være en tilnærming av en løsning på problemet, men i tillegg til å være noe ”ad hoc”, er jeg heller ikke sikker på om dette er kode som er gyldig etter Java og Thorup sine spesifikasjoner. Blant annet er jeg skeptisk til at klassen AdvancedRelations er en subklasse av Relations som igjen er en subklasse av C. Klassen C blir jo først definert i brukerprogrammet. Med andre ord vil jeg si at dette kan være et forslag til en tilnærming, men ikke en direkte løsning på problemet. Thorup sin artikkel er ikke så spesifikk at den sier om dette er lov eller ikke, men man kan merke seg at det i programmeringsspråket Beta i utgangspunktet er mulig å lage tilsvarende konstruksjoner, men der har de eksplisitt valgt å forby dem da det kan føre til kode som er sen å eksekvere, faktisk selv om mekanismen ikke brukes. 3 Forslag til generiske typer i Java 32 3.1.5 Sammendrag De virtuelle typene som Thorup presenterer, faller godt inn i Java sin nåværende standard. I utgangspunktet utvider Thorup bare mulighetene innenfor Java sine klasser slik brukerne allerede kjenner dem. Siden virtuelle typer kun opererer med reelle klasser, gir det nesten ikke mening å snakke om en homogen eller heterogen implementasjon. Implementasjonen blir helt naturlig homogen med de fordeler og ulemper det medfører. Virtuelle typer tar som sagt kun utgangspunkt i klassebegrepet, og dette utelukker dermed støtte for primitive typer. Dette er ikke kritisk siden Java i tillegg til forskjellige primitive typer, også har standard klasser som representerer hver av dem, men det er likevel en ulempe siden man av og til kan ha behov for å jobbe med de primitive typene direkte. Den største ulempen med virtuelle typer, er antakeligvis at mekanismen ikke har mulighet til å bli like kraftig som for eksempel parametriserte typer. Modellen bak mekanismen er kanskje teoretisk bedre fundert, men samtidig medfører dette at man blant annet ikke klarer å uttrykke eksempler som Mix-in. 3.2 Parametriserte typer, Agesen mfl. Ole Agesen, Stephen N. Freund og John C. Mitchell har skrevet artikkelen ”Adding Type Parameterization to the Java Language” [8]. I denne artikkelen diskuterer forfatterne deres inntrykk og syn på mangelen av generiske typer i Java, samtidig som de presenterer et komplett forslag til parametriserte typer. Forslaget til Agesen har mange fellestrekk med lignende forslag som har vært presentert før, særlig innenfor andre språk. Blant annet bruker Eiffel [21] parametriserte typer som har mange fellestrekk med Agesens, og her kan man blant annet også spesifisere generiske parametere med krav om at aktuellparametere er en subklasse av en spesifikk klasse. I Eiffel kan man for eksempel opprette en generisk klasse HashTable med krav om at en aktuellparameter skal være en subklasse av Hashable, med følgende kode: class HashTable[Element -> Hashable] ... end For de fleste problemtypene jeg presenterte i kapittel 2, illustrerte jeg der også en løsning ved hjelp av en mekanisme som tar utgangspunkt i nettopp de parametriserte typene fra [8]. Derfor gjentar jeg ikke løsningene i dette kapittelet, men diskuterer litt mer generelt om den tekniske løsningen. 3.2 Parametriserte typer, Agesen mfl. 33 3.2.1 Generelt om den generiske mekanismen Artikkelen [8] sitt forslag til parametriserte klasser, ligner syntaktisk en del på templates fra C++. Det hele bygger på at man skriver en ”halvferdig” klasse (kan kalles en generisk klasse) som tar en eller flere formelle klasseparametere, og klassen blir først fullstendig når den instansieres og man samtidig sender med spesifikke klasser som aktuelle parametere. Det er først da klassen blir ”fullverdig” og kan benyttes på lik linje som andre uparametriserte klasser. I tillegg til å legge inn støtte for parametriserte klasser, har de også innført parametrisering på interfacer. Parametriserte interfacer, kan blant annet gjøre det enklere å sette krav til binærmetoder, hvor typen vil variere fra bruk til bruk. Da forfatterne designet sitt forslag, tok de utgangspunkt i at følgende krav skulle oppfylles: • De parametriserte typene skulle være relativt enkle å forstå, slik at programmerere kunne ta dem i bruk uten dyptgående kunnskap om hvordan de fungerer. • De ønsket å forhindre innføring av nye begreper i Java, så fremt det var mulig. • De parametriserte typene skulle øke muligheten til statisk sjekking og til å redusere bruk av castinger (så lenge det var mulig), for på denne måten å kunne oppdage programmeringsfeil så tidlig som mulig og dermed også redusere kostnadene ved programeksekvering. • Mekanismen skulle støtte separatkompilering slik at man, i tråd med Java sin idé, statisk skulle kunne sjekke separate enheter for feil selv uten å kjenne de aktuelle parameterne. For å gjøre det mulig å statisk sjekke den generiske koden, har forfatterne lagt inn støtte for å kunne sette skranker på (eller ”spesifisere”) de generiske parameterne. Dette gjør de i utgangspunktet ved å la brukeren benytte de allerede kjente begrepene implements og extends, hvor de i denne sammenheng skal bety: • A implements I: Parameteren A er enten en klasse som implementerer I, en subklasse i en eller flere steg av en slik eller et interface som i null eller flere steg har I som et superinterface. • A extends B: Parameteren A er en subklasse av B i null eller flere. Disse to skrankene kan enten brukes hver for seg eller kombineres hvis det er ønskelig. Det vil derfor være fullt lovlig for eksempel å definere følgende klasse: class C {...} 3 Forslag til generiske typer i Java 34 I utgangspunktet gjør disse skrankene, på samme måte som for Ada, det mulig å statisk sjekke den generiske klassen separat, og generelt er det ikke så mye mer man trenger å tenke på når man programmerer ved hjelp av parametriserte typer. Likevel er det at par konstruksjoner man må være oppmerksom på, og som gjør at parametriserte klasser ikke er helt trivielle. Ta for eksempel følgende klasse: class C { void m(A s) {...} void m(String s) {...} } Dette vil være en gyldig klasse for alle parametere bortsett fra for klassen String. Hvis man sender med en String-parameter, vil klassen inneholde to metoder med samme grensesnitt, noe som vil være flertydig og som derfor er ulovlig i følge standarden til Java. Agesens parametriserte typer tillater derfor ikke at klassen C instansieres med typen String. Mekanismen tillater at man kan bruke primitive typer som parametere til generiske klasser; men selvfølgelig ikke der det forutsettes at parameteren enten implementerer et interface eller utvider en klasse. Hvis dette skal gjøres, er man nødt til å bruke de tilsvarende klassene for de primitive typene som leveres med Java. Som jeg viste i kapittel 2, tillater Agesens mekanisme at man henviser til en generisk parameter, som en del av spesifikasjonen av de generiske parameterne. Eksempelvis: class Relations> extends C { ... } Dette gjør at man får ganske fleksible muligheter ved deklarering av spesifikke parametere. Det teoretiske grunnlaget (kalt F-Bounded Polymorphism) for at dette blir konsistent, er blant annet gitt i artikkelen ”F-Bounded Polymorphism for Object-Oriented Programming” [25]. 3.2.2 Integrering av mekanismen i eksisterende JVM Forfatterne som har foreslått denne mekanismen, har også tatt utgangspunkt i at den skal være bakoverkompatibel med tanke på gamle JVM-standarder. De har imidlertid vært nødt til å gjøre en liten forandring på loaderen i den virtuelle maskinen, men denne forandringen får ingen følger for programmer skrevet for tidligere JVM-er. En JVM er bygget opp av fire forholdsvis atskilte komponenter, og loaderen er den første komponenten som en klassefil parseres av. Denne leser inn klassefila og henter eventuelt inn andre klasser som programmet er avhengig av. Se Figur 3.1. 3.2 Parametriserte typer, Agesen mfl. 35 Grunnstrategien til [8] er å kompilere en parametrisert klasse ned til en utvidet form for klassefil. I tillegg til alt som vanligvis lagres i klassefila, inneholder den utvidete versjonen også informasjon om parametere og skranker, og denne informasjonen er lagt inn i |
| File Format | PDF HTM / HTML |
| Alternate Webpage(s) | https://www.duo.uio.no/bitstream/handle/10852/10123/oppgave.pdf?isAllowed=y&sequence=1 |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
