For dem, som ikke kender Alex Buckley, så kan jeg fortælle, at han har overtaget Gilad Brachas plads som JVM'en kustode. Hans fornemmeste opgave er derfor at sige "Nej!" til alle de skøre forslag, som alle vi andre kommer med - og kun at lade en lille, vel gennemtænkt smule slippe igennem, så JVM'en og Java aldrig løber af sporet.
Om Gilad Bracha er der en lille anekdote: Jeg oplevede ham til JAOO for nogen tid siden (2005), og hans foredrag var om nye muligheder i JVM'en med henblik på at forbedre understøttelsen af dynamiske sprog (specifikt om invokedynamic). På et tidspunkt under foredraget kommer en slide op, hvor et punkt er markeret med "OMDB" (nederst s. 33 her). Jeg kan huske, at jeg sad og overvejede, hvad det stod for - "Object Method Data Base" eller måske "Overloadet Method Definition Basis". Vi kommer lidt længere hen inden at Gilad afslører, at OMDB står for "Over My Dead Body" - og det var det at jeg tænkte to ting:
- Hvor var jeg glad for, at vi havde en så konservativ person til at hænge i bremsen på noget som vigtigt som JVM'en.
- Hvis man siger sådan noget, hvad gør man så, hvis folk er villige til at tage en på ordet?
Nå, men jeg løber ud af en tangent - jeg ville jo snakke om Alex' blogpost om navngivne parametre...:
For dem, som ikke lige har tid til at læse Alex' blogpost, så kan jeg sige, at han identificerer to store fordele:
- Øgede muligheder for at skrive kode, hvor det er umiddelbart til at forstå hjensigten - og ...
- Muligheden for at angive parametre i vilkårlig rækkefølge, hvis de navngives (herunder nogle overvejelser om varargs).
og Alex konkluderer i Gilads ånd, at nr. 2 nok er en ide med store fordele, men at den vil have store problemer rent implementationsmæssigt - hvis man skulle bevare bagudkompatibilitet, vil det ikke er praktisk muligt, og der er andre udfordringer; hans holdning er dog, at nr. 1 allerede give så store fordele, at det er værd at overveje.
Jeg er enig.
...men nu er jeg også typen, som bliver irriteret hver gang jeg ser en metode, som tager en eller flere booleans som parametre, fordi at jeg ved, at jeg ikke om 3 måneder kan huske, om:
udskriv("en tekst", true, false)betyder, at der skal udskrives med bold og ikke italic, eller omvendt - og derfor ender med at skrive:
final boolean isItalic=true;
final boolean isBold=false;
udskriv("en tekst", isItalic, isBold);hvilket selvfølgelig øger antallet af kodelinjer med 200% (hvilket er skidt!), men som til gengæld klart giver udtryk for, hvad der var min hensigt, da jeg skrev koden (og det opvejer det efter min mening fuldtud).
Til gengæld er der tale om en noget af et deja-vu: Allerede i forrige årtusinde kunne man angive navngivne parametre i VAX-Pascal (VAX-Pascal fandtes til VAX/VMS mainframes fra DEC, og som sprog var det på mange måder forud for sin tid). Jeg husker ikke klart, om VAX-Pascal havde operator-overloading, men navngivne parametre var helt klart en del af sproget, som jeg brugte (ikke meget - bevares - som Alex er inde på, så er det nok mest en "smell" i grænsefladen, når man finder det nødvendigt) - og som jeg kom til at savne.
På samme måde har jeg stort set altid brugt parameterbinding i mine SQL-udtryk (fordelene er så mange og så indlysende, at jeg ikke vil nævne dem her) - og hver gang er jeg blevet irriteret over, at parameter-markøren i standard-SQL er et anonymt lille spørgsmålstegn. Som oftest har irritationen affødt, at jeg er endt med at skrive min egen lille wrapper, som tager en streng og et map (eller en lignende datastruktur), hvor der i stregen laves substitution på navngivne parametre, og at der formatteres en passende liste af parameterværdier. Det betyder, at man aldrig mere skal sidde og tælle spørgsmålstegn - og det betyder også dels, at man dels kan stoppe nye parametre ind i midten af et udtræk, uden at det hele kommer ud af sync - og dels, at man pludselig kan bruge den samme værdi flere gange uden at skulle gentage den.
Så, Alex, jeg er 100% bag dig - lad os få muligheden for navngivne parametre i Java - det er på høje tid!
2 kommentarer:
Jeg er også 100% for navngivne parametre i Java - ikke mindst fordi jeg lige nu sidder og mærker smerten ved at skulle kode op imod et API, hvor der er flere metoder, som tager temmelig mange parametre - hvoraf nogle af dem gerne må være null, såfremt andre af parametrene indeholder noget andet end null. Der er sågar en af metoderne, som jeg konsekvent kalder med tre null'er i midten af parameterlisten.
Havde jeg haft navngivne parametre, havde smerten ved det dårligt designede API selvfølgelig ikke været væk, men den havde været mindre.
Rasmus, det lyder ikke sjovt ... livet er for kort til dårlige API'er!
Måske er det værd at overveje at lave en wrapper til API'et? Det er dog en beslutning, som man ikke skal tage for tidligt; for man skal have en god forståelse af ens behov, hvis ikke man vil risikere at ende med at stå med noget, som er endnu dårligere!
Lige nu sidder jeg lidt og kommer i tvivl - der er nogen folk, som kvitterer for bedre værktøjer ved at ødelægge ting hurtigere, og jeg kunne godt frygte, at man ved at fjerne smerten ved lange, anonyme parameterlister, i virkeligheden gør det mere acceptabelt. På den anden side, så vil jeg tro, at signaturen ser ud som den gør, fordi de ikke selv har prøvet at bruge det for alvor... :-/
Når det er sagt, så skal jeg da være den første til at indrømme, at jeg selv har lavet min del af verdens uheld - jeg vil dog mene, at jeg har lært af det!
Send en kommentar