Generiske mekanismer i klasser og pakker

Transkript

1 Generiske mekanismer i klasser og pakker Stein Krogdahl OMS-seminar, 14. desember 2004 Noen temaer: Litt om de nye generiske mekanismene i Java 1.5 og C# 2.0 Hva kan være interessant ved å i stedet ha generiske pakker? Noen mekanismer som kan være aktuelle ved generiske pakker

2 Generiske klasser i C# og Java Hovedideen Anta følgende definert: interface I{ class C{ Definisjon av generisk klasse: C#: class G<T> where T:C, I { her kan T brukes som en vanlig klasse/type som har alt som er definert i I eller C Java: class G<T extends C implements I> { som over, men litt mer begrenset En mulig aktuell parameter: class AC extends C implements I{ (og tilsvarende for C#) Denne kan så brukes slik: G<AC> g = new G<AC>( ); Man må altså angi parameteren hver gang, og samme parameterisering gir samme klasse. C#: Generiske parametere kan være både klasser, interfacer, og grunntyper Java: Generiske parametere kan bare være klasser og interfacer

3 Generiske klasser i Java (versjon 1.5) Anta den generiske klassedefinisjon G<T extends C> { Java 1.5 har ingen runtime-representasjon av parametriseringen av en generisk klasse. Ting oversettes til gammel bytekode. Derfor følgende egenskaper: Man kan ikke caste til G<A> eller si instanceof G<A> Man kan ikke (inni klassen) caste til T eller si instanceof T. Alle klasser G<A>, der A er en aktuell parameter, har felles sett av statiske variable og metoder. Derfor: Typene på disse kan ikke avhenge av T I refleksive operasjoner ser objekter av alle klasser G<A> ut til å være av samme klasse. Altså om: G<A1> a1 = new G<A1>( ); G<A2> a2 = new G<A2>( ); så er følgende sant: a1.getclass( ) == a2.getclass( ) Bruker samme runtime-koden for alle parametriseringer av en generisk klasse.

4 Mer om generisk Java Anta den generiske klassedefinisjon: G<T extends C> { Man kan ikke (inni G) gjøre new T( ). Må bruke factory-teknikken Klassene G<A1> og G<A2> har ingen sub/super-relasjon til hverandre, heller ikke om A1 og A2 har det. (Altså ikke kovarians, som for arrayer). Joker-notasjon (wildcard): Man kan bruke G<?> eller G<? extends A> eller G<? super A> som type på variable m.m. (A må da være subklasse av spes. av G sin parameter.) G<?> kan altså sies å være en supertype til alle G<?>. Variabel G<?> g kan da peke til objekter av alle klasser G<A> Dersom G<C> gc, så går da g = gc, men ikke omvendt Man kan også bruke bare G som type. Dette kalles den rå typen, og den likner på G<?>, men mer er tillatt. Om man har et bibliotek som er laget med generiske typer, men man bare bruker klassene som rå typer virker dette som et tilsvarende bibliotek uten generiske klasser. (Stemmer dette fullstendig?) Om man i et program bruker G i både rå form og som G<A>, vil tilordning bli tillatt begge veier. Java gir da en kompilator-advarsel der det kan gå galt (men det blir ikke lagt inn noen runtime-test). Dette er for å kunne blande gammel og ny Java-kode.

5 Generisk C# (versjon 2.0) C# lager en runtime-descriptorer for alle brukte parametriseringer av en generisk type. Man kan derfor bruke casting og instanceof helt fritt, både med parameteren T (inne i G) og med klassen G<A>. Man kan (inni G) gjøre new T( ), dersom man har spesifisert T slik: class G<T> where T: C, new( ) { Kan dog ikke bruke konstruktører med parametere. Kan gi alias-navn til generiske klasser med aktuelle parametere: using GA = G<A>; I tillegg til generiske klasser og interfacer, kan man ha generiske struct er Det er gjort utvidelser i bytekoden (CIL), slik at den forstår generiske klasser/interfacer/structer (i motsetning til i Java). Derfor går tingene over greit. Bruker samme runtime-koden for alle G<A>, så langt det er mulig (oftest, så lenge de aktuelle parametrene bare er klasser/interfacer). Så vidt jeg kan se, ingen joker-notasjon.

6 Generelt for både Java og C# Det tillates ikke å bruke T som superklasse i en (indre) klassedefinisjon. Man kan bruke såkalt F-bounded polymorphism class G<T extends G<T>> En klasse som kan brukes som aktuell parameter for T er f.eks.: class A extends G<A> Man kan ha generiske parametere på metoder (gjelder også statiske metoder): Java: <U extends B>U getvalue (int i, U u) { kan anta at U har alt B har C#: U getvalue <U> (int i, U u) where U:B{ kan anta at U har alt B har Ut fra den konteksten en metode kalles i og fra de aktuelle parametere finner Java/C# nesten alltid den riktige typen av U. Den behøver derfor ikke angis. Det blir et utall av nye regler for navnebinding etc, f.eks.: Må passe på at det ikke blir dobbeltdeklarasjon av de to m-metodene i: class G<T>{ ; void m(t a){ ; void m(c a); Det blir problemer om G gies aktuell-parameteren C. Parameteren T er det greit at bare er synlig i klassen G, ikke i subklasser.

7 Interfacer til collection-klassene i Java Det kan virke kurant å gjøre om Collection-klassene i Java/C# til generiske varianter, men det er mange detaljer som skal stemme. Litt fra Javas generiske bibliotek (forenklet): interface Collection<E>{ void add(e o); bool containsallof(collection<?> c);... interface Comparator<T>{ int compare(t o1, T o2);... interface SortedSet<E>{ Comparator<? super E> comparator( ); E first( ); E last( );...

8 Vi kan forsøke et annet utgangspunkt: Generiske pakker i stedet for generiske klasser. Grunner for å forsøke dette: Implemetasjonen av begreper består ofte av flere klasser Eks: Graf (node og kant), SIMSET-liste (hode og element) Frameworks består av et antall halvferdige klasser, som kan utvides til å bli et ferdig program Det er selvfølgelig derfor begrepet pakker er laget i Java Det kan da være rimelig å parametrisere hele slike pakker som en enhet. Hver instansiering blir et helt nytt sett med klasser, og under instansieringen kan man gjøre alle slags substitueringer/transformasjoner/utvidelser man måtte ha lyst til. Typesystemet blir enklere, og svært mye kan gjøres ferdig i kompilatoren Grunner til ikke å satse på dette: Det blir noe mer statisk over pakker. Dette kan gjøre det hele mindre fleksibelt å bruke. Man kan i stedet bruke klasser inne i klasser, og parameterisere den ytre klassen.

9 Arbeids-syntaks generic package GP<T extends C> { class A{... ; T a = new T( );... class B{... class C{... // C i spesifiseringen av T bindes til denne // C kunne også være en klasse i en vanlig pakke X: inst GP<D>; // X er navnet på denne instansieringen av GP Y: inst GP<E>; // Navnet X/Y trengs ikke om man bare har en inst. class D extends X:C{... // D derved en lovlig parameter til X class E extends Y:C{... // Tilsvarende Merk at selv om begge instansieringene hadde hadde hatt samme parameter, så ville det likevel blitt to separate sett med klasser (i motsentning til for generiske klasser, der C<A> gjentatt flere ganger betyr samme klassen).

10 Collection-klassene som generiske pakker Føst en vanlig pakke med en interface som er supertyper til alle Collections (for å oppnå noe tilsvarende Joker-notasjon): package COLLOBJ{ // Pekere av denne typen kan peke til alle Collections interface CollObj{ void addobj(obj o); // Implementasjon: Test det er et E-objekt, kall så add. Object getobj( ); // Leverer et tilfeldig objekt, kaller get bool containsallof(collobj c); // NB: En vilkårlig Collection være parameter Så en generisk pakke med de parameteriserte interfacer og implementasjonsklassene: generic package COLL<E>{ import COLLOBJ; interface Coll extends CollObj{ void add(e a); E get( ); class CollImplA implements Coll{ impl. av add, addobj, get, getobj, containsallof,... class CollImplB implements Coll{ impl. av add, addobj, get, getobj, containsallof,...

11 Bruk av Collection-klassene package COLLOBJ{ // Som på forrige foil generic package COLL<E>{ // Som på forrige foil class Bil{ int vekt; class Person{ String navn; import COLLOBJ; // Uklart om det er nødvendig (følger dette av det under?) B: inst COLL<Bil>; P: inst COLL<Person>; B:Coll bc = new B:Coll( ); P:Coll pc = new P:Coll( ); bc.get( ).vekt = 2; pc.add(new Person( )); // Går helt greit CollObj co;... co = bc;... co = pc; // Går helt greit co.addobj(new Person( )); // Går greit om co angir en P:Coll if (pc.containsallof(bc))... // Går greit, og gir mening om Person er subklasse av Bil

12 Utvidelse til ordered collection Først en vanlig pakke med en interface som kan type alle ordnede Collections: package ORDCOLLOBJ{ import COLLOBJ; interface OrdCollObj extends CollObj{ Obj firstobj( ); Så den parameteriserte versjonen: generic packege ORDCOLL<E implements Compare>{ import ORDCOLLOBJ; inst COLL<E>; // Ta inn alle klassene etc. fra COLL, med E som parameter interface Compare {int compare(e e1, E e2);... interface OrdColl{ E first( ); class OrdCollImplA implements OrdColl{ impl av alle metoder... class OrdCollImplB implements OrdColl{ impl av alle metoder...

13 Oppsummering så langt Generiske pakker ser ut til å fungere sånn noenlunde som erstatning for generiske klasser, for en del rett fram behov. Men det må studeres mye mer om dette er fleksibelt nok til å dekke alle rimelige behov som generiske klasser dekker. Antakeligvis må man lage en forenklet syntaks for generiske pakker som bare inneholder én klasse, slik at den ser ut som en mer tradisjonell generisk klasse. F.eks. ved at følgende: generic package GC<E>{ class C{... kan skrives som: generic class C<E>{... Må man da bruke alias?: using CP = C<Person>; Vi skal i det videre se på andre muligheter rundt generiske pakker: Kunne utvide klassene med attributter/metoder som del av instansieringen Angi navneforandringer Kunne kombinere klasser fra flere generiske pakker til en felles klasse Noe nytt med hensyn til synlighetsregler Det er ikke opplagt at de forskjellige ideene til transformasjoner man kunne komme på vil gå godt sammen. Men: Forsøke å utrede mange muligheter først, så se hva som kan bli gode komposisjoner.

14 Tre nivåer for separat behandling av moduler Gjør bare syntakstisk sjekk av modulen, og gjør all semantisk sjekk og oversettelse når aktuelle parametere og andre forandringer er på plass. Slik virker templates i C++ Legg opp til å skulle gjøre full syntaktisk og semantisk sjekk av separate moduler, men ikke tenk på oversettelse. Da må f.eks. typeparametere spesifiseres. Legg opp til at separate moduler også skal kunne oversettes til en passelig kode. Merk her at det ikke er like krevende å oversette til bytekode/cil som til utførbar maskinkode. (I siste tilfelle bør relativadresser beregnes av kompilatoten, mens dette for bytkode gjøres i loaderen (ofte med JIT-kompilering). Vi skal her fortrinnsvis tenke i midterste nivå, så får man heller etterpå se hva som kan oversettes til hva slags kode.

15 Mulighet 1: Utvidelser av klassene ved instansiering generic package ANIMALS; class Animal{... class Mammal extends Animal{... void m( ){ class Horse extends Mammal{... class Dog extends Mammal{... void m( ){... // En redefinisjon class Insect extends Animal{... class Ant... inst ANIMALS expanding Animal, Mammal=>Mam, Dog; expansion Animal {... void m( ){ // En annen redefinisjon expansion Mam{... // Denne klassen får altså nytt navn expansion Dog{... m( );... // Hvilken redefinisjon blir da kalt? Man må her nøye lage synlighetsregler og regler for redefinisjoner. Hva om vi def/redef metoden m som over. Hvilken har da effekt ved kallet i ekspansjonen av Dog? Har tidligere kalt dette statisk arv, men det blir mindre rimelig å se det som arv/subklasser dersom en klasse med subklasser kan utvides.

16 Eksempel: Generisk pakke Graph generic package GRAPH expandable Node, Edge { // Oppgir de som kan ekspanderes. Fornuftig? class Node { Edge firstedge; / / First in the list of edges leaving this node Edge insertedgeto(node to){... / / Delivers the inserted new edge class Edge { Node from, to; Edge nextedge; / / Next in the list of edges leaving the same node void deleteme( ){ Bruk: inst GRAPH Node =>City, Edge =>Road; expansion City { / / Expansion of Node String name; / / In some method: int n = firstedge.length; / / OK, as type of "firstedge" is now Road City c = new City(... ); Road r = insertedgeto(c); / / No co- or contra-variance problems... expansion Road { / / Expansion of Edge int length;

17 Litt historie omkring ekspanderbare klasser Ekspanderbare klasser (der klassene ikke har subklasser i pakkene) kan sees som en slags virtuelle klasser til en modul, der bindingen av klassen gjøres når modulen brukes (instansieres) Behovet for noe slags virtuelle klasser, og en liknende mekanismen som den over, kom opp i arbeidet med Simula 85 (Arne W., Stein K., Jo P., Peter J.) i 80-årene. Er så beskrevet i Simula-sammenheng i rapporten On Modernizing the Simula language av Stein K. fra 1986 (Ifi-rapport), der også multippel arv i forbindelse med dette ble foreslått (samt div. andre ting). Beta-verdenen så det samme behovet, og at det kunne løses med deres virtuelle patterns ( Virtual classes: A powerful mechanism in O-O programming av Birger M.-P. og Ole L. M., OOPSLA 1989) Diverse hovedoppgaver: Lars Tafjord og Holm-Kjetil Holmsen: Implementasjon for Simula ( SiMod ) Endre Rognerud: Så på hvilke muligheter dette begrepet kan gi. Fredrik Sørensen (nå): Ser på en homogen implementasjon for Java. Eskil Blomfeldt (nå): Ser på en heterogen implementasjon for Java. Sigmund M. Nilssen (nå): Se mer på hvor fleksible generiske pakker er.

18 Mulighet 2: Slå sammen klasser fra flere generiske pakker til én Vi vil lage klassene City og Road på en annen måte. Vi tenker oss en pakke med klasser for datene som skal være med i City og Road: generic package GEOGRAPHYDATA expandable CityData, RoadData { class CityData {... class RoadData {... Vi har dessuten den gamle pakka: generic package GRAPH expandable Node, Edge { Bruk: inst GEOGRPHYDATA with CityData =>City, RoadData =>Road; inst GRAPH with Node =>City, Edge =>Road; expansion City {... Noe mer her?... expansion Road {... Noe mer her? Tanker: Hva skjer her om for eksempel CityData og Node hadde subklasser i pakkene? Går det bra? Skaper det noe interessant? Dette har et snev av noe som i det siste er kalt Traits (metode-samlinger som kan settes sammen på forskjellige måter for å danne klasser). Dette er også omtalt (av meg) som multippel statisk arv, og dette kan behandles ferdig i kompilatoren. Problem: Om for eksempel CityData og Node har vanlige superklasser vil vi få full multippel arv, som ikke kan behandles ferdig i kompilatoren.

19 En generisk pakke kan sees som en rolle-modell Noen generiske pakker Instansieringer av de generiske pakkene, der klasser fra forskjellige pakker er slått sammen

20 Mulighet 3: Privat instansiering Generiske pakker bør ha synlighetsregulering (private, public, etc.) som vanlige pakker, men kanskje noe mer: Anta at vi skal skrive en pakke DATABEHANDLER (generisk eller ikke), og at den trenger f.eks. et listesystem for å kunne holde på noen interne data. Vi har et slikt listesystem i den generiske pakken: generic package LISTSYSTEM expandable Elem{ class Head{ Elem first; class Elem{ Elem next; // Kan altså ekspanderes med bruker-data (generic) package DATABEHANDLER { private inst LISTSYSTEM Elem => DataPakke; expansion DataPakke { Data i pakkene Dette skal bety at alt som LISTSYSTEM-pakken gjør synlig utad er fullt synlig inne i pakka DATABEHANDLER, men utenfor denne er intet om LISTSYSTEM-pakken synlig. Dette gir nå en kraftig beskyttelse, ved at pakken DATABEHANDLER jo får sitt helt private sett av klassene i LISTESYSTEM. Om pakken LISTESYSTEM ikke hadde vært generisk, så hadde private import hjulpet lite: Alle kunne alle fått adgang til innholdet (inklusive statiske data) ved bare å gjøre en egen import av denne pakken.

21 Mulighet 4: Tillate formelle klasser som superklasser Dette tillates altså ikke i hverken generisk C# eller Java, og virtuelle superklasser tillates ikke i Beta (men for templates i C++ vet jeg ikke). For generiske pakker kan det imidlertid være mer fristende å tillate dette, siden alt her er så statisk, med et enkelt typesystem. Dette kan bl.a. gi mulighet til såkalte mixin-klasser, altså klasser som forutsetter visse egenskaper av en (ukjent) superklasse, og som da legger på visse ekstra egenskaper. Eksempel: Vi vil lage en mixin-klasse som for klasser som har boolske metoder eq og lt, legger på metodene ne, gt, leq og geq. En pakke som implementerer dette kan se slik ut: generic package ADDREL <T implements SimpleRel> { interface SimpleRel{ bool eq(t o); bool lt(t o); class FullRel extends T{ bool ne(t o) { return! eq(o); bool gt(t o) { class Car{ bool lt(car c){ ; bool eq(car c){ ; inst ADDREL<Car>; // Merk at det her ikke bør forutsettes at Car implemets SimpleRel på forhånd.

22 Mulighet 5: Kunne forandre navn inni klassene når en pakke instansieres Dette er en opplagt nyttig mulighet som det ikke er problematisk å lage en rimelig syntaks for. Merk at dette er svært uproblematisk, siden vi lager et helt nytt sett med klasser ved hver instansiering. Ser ikke her på noe konkret forslag. Mulighet 6: Lage enkel syntaks for en generisk pakke med bare én klasse Dette må nok gjøres for at det ikke skal bli for tungvindt å gjøre enkle ting. Fordel: Ved å trekke inn en del av de mulighetene som er diskutert her kan slike generiske klasser gies noen flere muligheter enn det som fins for eksempel i Java og C# På den annen side: Noen av de egenskapene som kan brukes fritt i generisk Java og C# (f.eks. full F-bounded polymorfisme) kan være problematisk å få inn.