var x = myLib.getData();
ezután honnan a szent tehén tőgyéből derül ki, hogy az x-nek milyen változói vagy metódusai vannak,
hogy a könyvtár írója a következő verzióban nem vesz-e el 2 változót, és ad hozzá 3 metódust?
1. Erre a megoldas az, hogy a programodat ugy irod, hogy megadod, hogy milyen verzioju libekkel fut.
2. A libeket ellenorzod (automatikusan), hogy a legujabbak-e.
3. Teszteket irsz (travis-ci.org/com pl.), es amikor a libbel verziot ugrasz, akkor rogton kibukik ha inkompatibilitas van.
Szerintem a fenti problemara (magyaran egy library fejlodik), sokkal jobb megoldas, amit most a node.js nyujt.
Ettol persze igazad van, a javascript nyelvi szinten erre megoldast nem nyujt. De nem is a dolga, mivel van ra jobb megoldas.
2, azért általában, mert voltak olyan változások, amik inkompatibilissé tették a verziók között, de ezen változások csak nagyon kevés alkalmazást érintettek (átnézve a saját 10+ éves kódbázisunkat, nálunk nem volt ilyen).
Ez a szerveroldal. Most vegyel elo egy random kliens oldali java programot 10 evvel ezelottrol es probald futtatni.
3, most a külső könyvtárakról, vagy a belsőkről beszélünk? A belső könyvtárak rommá vannak optimalizálva, de azokba nem kell nézelődni, mert minek.
En a belsokrol beszeltem, es hoztam fel peldanak.
Az egesz Hevi hozzaszolasabol jott, ahol o ezt irta:
Egyszer (minden irónia nélkül) úgy megnéznék egy Szépnek mondott JS projectet.
Erre megjegyeztem (ironikusan), hogy a java belso konyvtaraitol (ami alapban jon, tehat annak kellene a legszebbnek lennie:)) kifolyik az ember szeme:) Kb. mintha assembly-t olvasna.
Erre mondtad, hogy az assemblyre nem is hasonlit:)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....