uio-jpt/pt-compiler — Issue #18: Merge av klasser med typeparametre
Author: eyvindwa
Created: 2012-02-24 10:46:26+00:00
State: open

Her er det foreløpig litt uklart hvordan løsningen bør være. Til diskusjon:

**Alternativ 1**: Bare klasser uten typeparametre kan merges (dagens situasjon).

Dette er jo trygt og godt, men ganske restriktivt.

**Alternativ 2**: Om en templateklasse har typeparametre, så kan den merges med en annen templateklasse gitt at den klassen den merges med er abstrakt og ikke selv har typeparametre på klassenivå (selvstendige typeparametre på metodenivå holdes utenfor denne diskusjonen, og bør være uproblematiske). Den kan heller ikke ha subklasser.

Dette *bør* være trygt ettersom man for den abstrakte klassen aldri kan lage objekter av den, og dermed heller ikke "ødelegge" for den klassen som har typeparametre. Man kan dog lage pekere som refererer til den, f.eks.:

```java
template T { abstract class A { public A a; } }
template U { class C { T t; } }

package P {
inst T with A => AC;
inst U with C => AC;

class AC adds {
public void m() {
println(new AC().a.t); // <-- t vil her være typet som Object. Kan føre til "unchecked"-advarsel fra kompilatoren
}
}
}
```

Som eksempelet over viser, så vil man med denne løsningen kunne havne opp i situasjoner der man i addition-klassen får at ting er "unchecked", men dette gjelder så vidt jeg kan se ikke for noe av koden som allerede måtte stå i klassene A eller C over. Dermed tenker jeg at dette er en ulempe man for så vidt kan leve med for å vinne litt fleksibilitet.

**Alternativ 3**: Klasser kan merges dersom de har samsvarende typeparametre (altså samme antall og samme constraints).

Typeparametre skal da slås sammen, slik at den resulterende klassen får like mange typeparametre som hver av de opprinnelige klassene. Dette virker i utgangspunktet kurant, dersom man forutsetter at typeparametrene man slår sammen er HELT like.

**Alternativ 4**: Både alternativ 2 og 3.

En merge kan altså gjøres dersom klassene som slås sammen tilfredsstiller enten alternativ 2 eller alternativ 3. Dette er åpenbart den mest fleksible løsningen.

**Kommentar fra Stein (lettere parafrasert)**

Kan man gjøre noe med inst-setningen slik at man har bedre kontroll på dette? Altså f.eks.

inst T with A => AC;
inst U with C => AC;