Az a vicc, hogy főleg GUI-t fejlesztek, amit lokalizálunk is. Ennek ellenére már eddig is rengeteget szívtunk a véletlenül rosszul használt lokalizált Java API-val :-). Nem az a bajom, hogy léteznek nyelvfüggően működő metódusok. Hanem az, hogy ezeknek implicite paramétere az aktuális default locale ahelyett, hogy át kellene adni nekik explicite.
Miért probléma ez?
* Könnyű benézni, hogy az ember lokalizált, vagy lokalizálatlan metódust akar-e. És akkor ugyanaz a kód különböző gépeken különbözően működik. Ezek nehezen lekövethető hibákat jelentenek, amik többnyire nem a fejlesztőnél jönnek elő. Hanem élesben.
* .NET-ben ritkán dolgozom. A startsWith metódus különböző nyelvekből régóta ismert, tehát minden programozó a megszokott működést fogja várni tőle. De mivel téma lett, ezért a String.StartsWith doksiját direkt megnéztem most. A culture függő működés a megjegyzések között van. És az, hogy ez mit jelent konkrétan, további olvasgatással derül csak ki! Szerintem egyáltalán nem intuitív, hogy másképp működik ez a régi jó metódus mint eddig. Tehát aki több platformon is dolgozik felváltva, az még könnyebben benézi az ilyesmit.
* Nem ér semmit a tesztelés sem, csak akkor ha _mindent_ "keresztbeszorzol" az összes lehetséges locale beállítás kombinációval. Pláne hálózati protokollok esetén jó ez, mert akkor mindkét oldalt keresztbe kell szorozni.
* Még azt mondani sem elég, hogy "legyenek tökéletesek a fejlesztők, akik a teljes API doksit fejből nyomják, és soha nem felejtik el". A hibák jelentős része ugyanis nem is a saját kódodban lesz - lásd dong0 Oracle driveres hozzászólása.
* Ahogy Hunger írta, a teljesítményre is rossz hatása van az ilyesminek. A néhány bájt nyüstölése helyett 100 különböző objektum jön képbe mindenféle interfészeken keresztül.
* Szemantikailag is kb értelmetlen ez a fajta startsWith. Ugyanis valóban lokalizált stringre felhasználó által beírt kezdeményre van értelme használni, ilyen esetekben pedig kifejezetten idegesítő az, hogy a t, ty beírásakor a találati halmaz "ugrál"
* Mennél bonyolultabb az alap API, annál kevésbé lehetséges kompatibilis alternatív implementációt készíteni - lásd Mono. (gyanúm szerint ezt az egészet a Mono ellen csinálták, és a népszerű alapkomponensekbe tettek olyan kódot, ami a mongol StartsWith nélkül elszáll :-)
* Mivel ezek a nyelvfüggő dolgok kis nyelvek esetén alig teszteltek, ezért tele szoktak lenni hibákkal. Nem jó pontenciálisan alig tesztelt kódot tenni az alap API-ba.
* A teszteletlenség és hatalmas átláthatatlan kódbázis miatt ilyen jellegű API-k még biztonsági lukakat is jelenthetnek (.NET-ben kevésbé, de nem menedzselt kódokban simán).
* Lazán idetartozik a lokalizált - de valójában a fejlesztőnek szóló - hibaüzenet esete, amit szintén tüzes-vassal kellene irtani :-). De legalább hibakódot kellene adni mellé, ami keresőbe beírva egyértelmáen azonosítja a problémát.
Miért nem lenne probléma, ha explicite meg kellene adni a locale-t?
* A legtöbb programban futás közben lehet nyelvet váltani. Tehát a programfutás alatt állandó default locale eleve értelmetlen (tudom, .NET-ben lehet thread szinten állítani). Vagy eleve egyetlen program kezel több nyelvet - pl egy többnyelvű webszerver esetén. Az ilyen jellegű programok általában explicite kezelik a nyelvek kérdését.
* Ha nem működik a nyelvesítés a felhasználói felületen valahol, azt könnyen ki lehet szűrni teszttel ellentétben a fordított esettel.