Weblabor

A legszebb az egészben, hogy például JS-ben is a PHP4 konstruktorához hasonlóan hozunk létre objektum prototípusokat.



Kedves Práger Ádám, blacksonic és vbence, majd ha az ecmascript fórumain ott látlak titeket harcolni ez ellen, akkor majd lesz miről beszélnünk. Addig is, úgy látszik, előbb lőttök, és utána kérdeztek, és akkor nagyon finoman fogalmaztam.

Részemről nem adnék teret az ilyen szintű irományoknak. Az értelmes tartalom pár bekezdésben összefoglalható (kis jóindulattal), a többi csak arra jó, hogy két bekezdésenként változatos jelzős szerkezetekkel illessen mindenkit, aki nem ért egyet vele vagy bármi köze volt a nagyon-nagyon sérelmes történésekhez.

Amúgy nyilván nem jó gyakorlat, hogy csak úgy kivesznek egy funkciót egy olyan eszközből, amit rengetegen használnak. Amikor még követtem a PHP világának történéseit, ilyenkor előbb deprekálták, valamint ha használtad, sűrű warningokat dobált a rendszer. Aztán idővel el is távolították, ami nyilvánvalóan kívánatos és szükségszerű lépés.

Egyébként teljesen valószínűtlennek tartom, hogy a PHP7-ben csak úgy töröljék ezt az ősi konstruktoros megoldást, hirtelen ezt találtam, ami azt támasztja alá, hogy a fejlesztők is abban a megoldásban gondolkoznak, hogy 7-esben deprekálás, 8-asban viszlát (a szavazás pár hete zárult le).

Talán abból lehetne tanulni, ha rossz példaként állítjuk a cikk szerzőjét. Azzal az idővel és energiával, amit az iromány (szerintem felesleges) megalkotására fordított, simán készíthetett volna egy kis scriptet, ami az összes projektjében lecseréli a régi szintaxist az újra, merthogy amennyire én látom, ez baromira nem bonyolult feladat (jó ideje nem PHP-ztam). Esetleg ezt a kis eszközt meg is oszthatta volna az általa hangoztatott közösséggel. Biztos vagyok benne, bár nem néztem utána, hogy volt, aki ezt tette (szerintem már akkor, amikor a PHP5 megjelent), így a probléma megoldása még egyszerűbb. Mire lesz PHP 7, a PHP 4 támogatásával már nem éri meg foglalkozni - már ma sem nagyon lelhető fel sehol (eszerint 2% alatt van). Ha mégis ez a szíve vágya, hasonlóan kicsi szkriptekkel könnyen készíthet két különböző verziót a projektjéből.

(tényleg zárójelben: ha ezt tette volna, utána büszkén írhatott volna róla egy egész másfajta, pozitív irományt, ami után biztos vagyok benne, hogy ő is sokkal jobban érezné magát - fortyogó düh vs jól végzett munka és másokon segítés öröme)

Szerintem fejlesztőként, bármit is használunk, nekünk is van felelősségünk. Ha arra építjük a munkánkat, amit mások ingyér bocsátanak rendelkezésünkre, minimálisan elvárható, hogy alkalmazkodunk, követjük a változásokat és nem pedig elvárjuk, hogy mindenki más a mi hitvány kis kódbázisainkhoz alkalmazkodjon, amíg világ a világ. Ha egy projektet úgy készítünk el, hogy az nem fenntartható és magasról teszünk mindenre, ami ezt elősegítené (tehát eleve eldobhatóra készítjük, ami bizonyos esetekben persze a megfelelő döntés), nem várhatjuk el, hogy a kis projektünk évek múlva is ugyanúgy működni fog, miközben a környezet, amire épül, fejlődik. Ez szimpla önzés. Attól, hogy a közösségben rengeteg a hasonlóan önző stratégiát követő ember, a közösség érdeke még nem az lesz, hogy minden, ami működött a PHP 4-ben, működjön a PHP 22-ben is. A közösség érdeke az, hogy a fejlesztők továbbra is örömmel és hatékonyan dolgozzanak azon, hogy a termék minél faszább legyen. Bár a közösséget szolgálják, nem a közösség szolgái.

Mint már feltűnhetett, nem a visszafelé kompatibilitás ellen érvelek. Szerintem is fontos, hogy meglegyen a megfelelő stratégia, amivel szép lassan kivezetik az elöregedett, feleslegessé vált funkciókat.

Az írásban van egy másik nagyon fontos gondolat:

There are some developers out there who think that a project is never complete but always "work in progress" that needs constant refactoring. They assume that when a new version of the language is released that all developers will revisit existing code to see if it can be upgraded to include any new functionality, or simply to achieve the same result in a different way. This is *NOT* how things happen in the real world. Once a unit of work has been delivered to and accepted by the customer then that unit should be left alone until there is a very good reason to go back to it. I deal with enterprise applications which contain 2,000+ units of work, and if you think that I am going to examine all of those units each time a new PHP release comes out then you are seriously deluded. Taking time out to "fix" code which doesn't need fixing is non-productive and therefore not appreciated by the paying customer who wants improvements in the application that he can actually see.

Az itteni hozzászólások 100x érdekesebbek a cikknél... :)

Azért tényleg kicsit gáz 3 fő verzióval korábbi dolgokért sírni. Bár az array () nekem megszokott.