joeblade: bewijst dus niets.
Probeer ik iets te bewijzen dan
Ik geef een voorbeeld van het gebruik van geparameterizeerde typen...
maar zodra je dit object doorgeeft aan een andere functie
moet deze andere functie wel precies weten wat voor object dit is. (volgens mij)
Nee, je kan generieke functies definieren over een geparameterizeerd type waarbij het helemaal niet nodig is om het type van de elementen te weten. Sterker nog: dit is juist de kern van het systeem.
Ik geef even een ingewikkeld voorbeeld, waarin het goed tot zijn recht komt, maar het kan ook wel met simpelere voorbeelden worden gedaan.
Stel dat ik een lijst heb met paren van integers, strings en ik wil alle eerste elementen van die paren hebben. Dat kan uiteraard met een functionele aanpak via map fst.
Dergelijke zaken kan je nu zonder extreem veel casts volledig type safe implementeren in Java. Dit betekent dus dat de compiler de type-correctheid van je applicatie kan controleren en dat is (vind ik) erg belangrijk.
Ut voorbeeld:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| public class Map<A, B> implements Function<List<A>, List<B>>
{
private Function<A, B> _function;
public Map(Function<A, B> function)
{
super();
_function = function;
}
public List<B> apply(List<A> argument)
{
List<B> result = new ArrayList<B>();
Iterator<A> iterator = argument.iterator();
while(iterator.hasNext())
{
B element = function.apply(iterator.next());
result.add(element)
}
return result;
}
}
public class First<A, B> implements Function<Pair<A,B>, A>
{
public A apply(Pair<A, B> pair)
{
return pair.getFirst();
}
} |
Zowel de functie Map als de functie First zijn nu volledig generiek en te controleren op type correctheid (in Java kan dit dus gecompileerd worden. Het dient niet als template).
hoe is dit makkelijker? de rest van je applicatie moet nu ook ineens weten dat een string en een pair aan elkaar vast zitten.
Nee dat is niet helemaal zo. Inderdaad moet je wel initieel opgeven op welke typen je wilt parameterizeren, maar alle andere functionaliteit kan je generiek gebruiken. Geen enkel punt.
als ze beiden van type Object waren geweest dan hadden al die types niet door hoeven filteren op plaatsen waar ze waarschijnlijk helemaal niet nodig waren geweest.
Types doorfilteren? Als het objecten waren geweest had de compiler veel minder kunnen controleren. Casts zijn niet te checken op type correctheid en moeten dus vermeden worden... Dergelijke constructies zorgen voor bugs en lastig debuggen...
jullie doen alsof casten zoiets naars is. het scheelt je juist een hoop geklooi. als je die "afunction" aan wilt roepen en je bent alleen geinteresseerd in "Pair" en niet in "String" of "Calendar".. dan ben je met templates flink genaaid.
Bij geparameterizeerde typen hoef je niet percee te parameterizeren. Je kan ook geen parameters opnemen. Mooi he?
verbergen van types (en daarbij het "moeten" casten... is juist handig, en niet erg. als je het daarmee niet eens bent, hoor ik graag goede argumenten.
)
Verbergen van types is handig
Nadelen van jouw oplossing:
1. Geen type-safety
2. Geen compiler checks
3. Performance verlies door casts
4. De code is niet zelf-documenterend.
Al deze voordelen heb je wel bij geparameterizeerde typen...
/u/2046/pooh2.png?f=community)
.:strip_icc():strip_exif()/u/6988/greg.jpg?f=community)
/u/3813/100_8985_ICON2.JPG?f=community)
:strip_exif()/u/5197/Final_Fantasy_7_-_Red_XIII.gif?f=community)
.
