Vlákno názorů k článku Základy programování ve Squeaku od andy - Videl som screencast, kde autor menil bežiacu hru...
-
Jan Vrany (neregistrovaný)
No to je odpoved za vsechny prachy :-)
Ale k veci. Otazka je co myslite zmenou struktury. pridani/odebrani/zmena metody neni problem, metody se drzi kontejneru ve tride daneho onjektu.
Zmena layoutu objektu (pridani/odebrani instancni promenne – fieldu chcete-li)
je zajimavejsi. Na to jsou v zasade dve reseni:
1) vytvori se kopie nove tridy se patricnymi zmenami a ta se nainstaluje do
systemoveho slovniku. Stare objekty (vytvorene pred zmenou) si referencuji
starou tridu…az vsechny stare objektu vymrou, pojde i trida (je treba si
uvedomit ze tridy. metody, bytekod – to vsechno jsou normalni objekty
pod nadvladou GC)
2) Objekty se zmigruji na novou verzi. Data se proste „prekopiruji“ tak. aby
to vyhovovalo novemu layoutu. To je trosku tricky a aby to slo udelat
efektivne (rychle) je potreba pouzivat neprime ukazatele na objekty
(jako VW a GST). Squeak (a St/X ci Dolphin) pouzivaji direct-pointers,
takze tam je tahle operace relativne draha.
Vetsinou se pouziva ta prvni varianta, nebot je to jednodussi na implementaci,
vetsinou to staci a kdyz ma nekdo potrebu, tu druhou variantu si muze vzdycky
naprogramovat (a je to na par radek, alespon ta zakladni verze)
Nekonzistence dat: to je otazka co to znamena. Pokud to znamena ze si date
do objektu bordelni data, pak budiz Vam zeme lehka :-) -
andy (neregistrovaný)
No v podstate sa dá ľahko pochopiť, čo to robí pri jednoduchých zmenách – v danom prípade priradil inú farbu asteroidom, engine hry pri nasledujúcej iterácií zbehne danú metódu a proste budú mať asteroidy novú farbu.
Ale keď zmením triedu tak, že zmažem (inštančnú) premennú a niekde sa na ňu odkazujem…to je ten prípad čo popisujete..dovolí mi to vôbec „update“? (dalo by sa to otestovať, ale nemám moc čas teraz študovať smalltak a squeak)
Ďalšia vec – predpokladom je, že vďaka zapúzdreniu sa na tú premennú odkazujem len v mojej triede. (hoci ak mám k dispozícií celý image, asi sa to dá ošetriť aj bez toho)
To 1) riešenie sa mi zdá trochu zbytočné, napr. objekt Application s referenciami na moje objekty asi za behu nevyhynie.
Zaujímam sa o toto, lebo som čítal niekde o EVE Online, ako vďaka stackless pythonu, citujem
„We can make changes to the code and see the effects in the running client or server without restarting them.“.
čo ma dosť zaujalo, ale ani po dlhšom googlení som nezistil, ako je to konkrétne realizované, vyzerá to skôr na nejaké in-house riešenie. -
Smalltalk s takovými zásahy počítá. Pokud odstraní používaná instanční proměnná, překompiluje se změněná třída a její podtřídy. Pokud se neexistující instanční proměnná někde používána, dá se na její místo asociace na nil, která se uloží do globální kolekce Undeclared. Takže například všechny accessory na danou instanční proměnnou ve všech objektech dané třídy začnou vracet nil (bez vyhození výjimky). Z jiných tříd se na instanční proměnné jako takové odkazovat nejde. Pokud se použila někdy před tím, muselo to být pomocí zavolání zprávy a pak se referencuje konkrétní objekt, kterého se změna ve třídě jednoho objektu, který ji referencoval nebo referencuje, nijak netýká.
-
Jestliže se smaže třída (např. Person), která má instanční proměnné, je někde používána nebo má podtřídy, je nahrazena tzv. obsolete třídou (AnObsoletePerson) a přidá se do kolekce obsoleteClasses. Díky těmto kolekcím (Undeclared, obsoleteClasses) se podobné nekonzistence v systému hledají a odstraňují poměrně snadno.
Smalltalk relativně bez úhony přežije i poměrně brutální zásahy. Pokud si ale pod sebou uřežete větev obzvláště bezohledně, většinou o provedené změny nepříjdete, protože se postupně logují do souboru changes a dají se snadno zrekonstruovat.
