Nem, alkatrészt ültetek be, vagy funkciótesztet végzek, illetve egyéb, attól függ éppen milyen melót osztanak ki rám 🙂

Volt egy verzió amiben két KDE is volt, a KDE2 és a KDE3 béta. A default desktop ha jól emlékszem a KDE3 béta volt, de volt mellette egy KDE2 is mert az alkalmazások jó része csak arra volt meg. Viszont a KDE-nek még sok-sok bugfix release kellett az ott kiadotthoz amíg igazán stabilnak lett nevezhető. Nekem a SuSE 9-ben volt elég nagy szívásom vele (pedig abban már rég a „stabil” KDE3 volt), a kate crashelt egyet mentéskor, de úgy hogy azt a fájlt is agyonütötte amit épp szerkesztettem (telirakta szeméttel). Ilyet se azelőtt se azóta nem csinált szövegszerkesztő, akkor picit kiakadtam (le is cseréltem Mandrake-re).

Pontosan. De az elindul más archon, a Windows meg nem (eddig egyedül a 2k tudott nálam egy másik gépben bootolni, de az is megpusztult elég gyorsan utána).

Na ja. De ennek az ára egy boot manager ahol különféle kernel verziók közt választhatsz. Ez mondjuk linuxon nem annyira feltűnő, mivel ott általában amúgy is ott figyel a másik partíción a windows, de amúgy annyira nem nagy öröm hétköznapi használat esetén (vagy mindig nyomsz egy plusz entert induláskor, vagy vársz 5-10 másodpercet ami azt jelenti hogy ennyivel nő a boot ideje).

Lehet, de még mindig tartom a véleményem, hogy a property felesleges dolog. Győzz meg az ellentétéről, de én még nem láttam égető fontosnak a dolgot. Inkább gányolás szaga van, mert megengedi, hogy algoritmussal állíts elő egy változóértéket, ami nem szép dolog. Ha úgy működne, hogy a láthatóságát/hozzáférhetőségét lehetne vele árnyalni, vagy hasonlóan, mint a postgres-ben a check constraint, akkor OK lenne.

Lehet vele, Pl. ha read-only property-t akarok akkor nem írom meg a settert és máris csak olvasni lehet. De lehet mást is csinálni, Pl. ha egy adott tulajdonságnak olyan értéket adok amit nem vehet fel, akkor értékadáskor dobhat egy szép nagy exception-t. De eleve, ha belegondolsz Pl. egy label objektum ott figyel a formon. Neki van egy text tulajdonsága, ő egy string, azt a feliratot jelképezi ami rá van írva a címkére. Logikusan ő egy text mező lenne a Label objektumba, és a Label1 nevű címkéd feliratát úgy tudod „helló világ”-ra állítani hogy label1.Text=”helló világ”. Merthogy az az ő felirata. Az hogy a label objektumon belül mi zajlik lényegtelen, számodra fekete doboz, neked arra van szükséged hogy ha megváltoztatod a Text mező értékét akkor az legyen a felirat. Igen ám, csakhogy ha nincs property-d, akkor a mező értékének változásáról az objektum nem értesül, azaz a Text mezőt fölülírhatod, de ettől a képernyőn a felirat nem fog megváltozni csak ha ez után kiadsz egy újrarajzolást forszírozó függvényhívást is. Nos, erre találták ki a javások a getter/setter függvényt ami valóban gányolás, hiszen az objektumban valójában mezőként szereplő dolgot  függvényeken keresztül piszkálgatom csak azért hogy az objektum értesülhessen arról hogy változott az értéke. Plusz, hogy még szebb legyen, ha megnézed egy vizuális designerben a label objektumot ott már a Label-nek adsz értéket a Netbeans-ban a propety editorral (miközben a labelednek nincs Text propertyje, sőt a nyelvben sincs property). Persze messze nem ez a legborzasztóbb dolog amivel programozási témakörben találkoztam, egy vizuálbézikhez ez még mindig egy álom, nem is beszélve az RPG-ről, a COBOL-ról, a 6502-es assemblyről, csak 2007-ben azért annyira nem elegáns. Elvben egyébként valóban lehetne property-hez hasonló dolgot utólag is kreálni egy nyelvben, azaz az objektum kiértesítse a tulaj objektumot hogy változott a helyzet, csak ehhez operator overloading kellene, ez pedig a javából szintén kimaradt.
És persze a dolog nem csak vizuális osztályoknál érdekes, normál osztály esetén is jól jöhet ha az osztály értesül arról hogy egy mezője változott vagy ha algoritmus alapján tudom kiszámolni az értékét. Pl. jó kis cache kezeléseket lehet így csinálni (a getter vagy lerántja a szerverről az adatot vagy ha már megtörtént akkor a lokális értéket szedi elő) és még kismillió más dolgot – úgy hogy az osztályt használó program nem is tudja hogy belül mit csinál a rendszer. Nem is kell tudnia, nem az ő dolga. Tudod: egységbezárás… Neki azt kell tudnia hogy annak a mezőnek az értéke ezt és ezt tartalmazza. Az hogy az objektum ezt hogy reprezentálja belül az nem az ő dolga. Míg a getter/setter eleve függvényhívást feltételez – azaz rontja az egységbezárást. Legalábbis szvsz.

Eddig 1.5 MB-nyi php kódot hoztam össze, de soha nem volt olyan gondom, ami a gyenge típusosságból ered. A belső változóimról tudom, hogy milyenek lehetnek (ha nem, akkor meg… ezért szeretem a java-ban az exceptionokat 🙂 ami megjelent a php5-ben, de elég kezdetleges, a php6-ra lesz igazi), a külsőket ($_{GET,POST}) meg ellenőrzöm rendesen.

Ami késik nem múlik. . Az exception jó dolog, de ha kiváltódik (anélkül hogy lenne egy catch ami elkapná, és a júzernél landol) akkor már gáz van, az annak a jele hogy valaki valamit elkúrt, nem kicsit de nagyon. Sokkal jobb ha a hibák minél nagyobb részét a fordítás során tolja az arcodba a rendszer.

Voltak ott durvább dolgok is a régebbi rendszerekben, Pl. csomag inkozisztencia (X csomagnak az adott lib-ből az N verzió kell, de az N+/- 1 van a rendszerben meg ilyenek).

Ez így világos, de: ha egy értéket akarsz megváltoztatni, akkor simán public változó, ha meg mást is akarsz csinálni, akkor pedig függvény. Szerintem ez így logikus(abb). Megértettem, hogy mi az a property, de nekem abba a kategóriába kerül, hogy „ha van, akkor használom, ha nincsen, akkor nem hiányzik”.

Ha egy programnyelvben nincs OOP akkor megcsinálom a dolgot OOP nélkül (már ha eleget fizetnek érte ). De ha egy mód van rá akkor az OOP-set választom. Ugyanez a helyzet a propertyvel is.