To je celkem logicky, ze by se tahle struktura mela vyskytovat minimalne. Jeji opakovani by se melo eliminovat prave polymorfismem (nebo jeste lepe tady diky tomu, ze chybi kontrola typu, tedy polymorfismus v puvodnim slova smyslu, zasilanim zpravy instancim ruznych trid).
Presne tohle jsem cetl v jedne knizce o Smalltalku: nad kazdym case se zamyslete, jestli tam nahodou misto toho nepatri volani polymorfni metody. Myslim ze je to dost dobry napad pokud se podobne case v programu opakuji a ocekava se pridavani dalsich case-vetvi v budoucnosti. A to samozrejme plati nejen pro Smalltalk.
Zdravim a chci se Te zeptat, jak je efektivni (pametove i vykonove) neexistence primitivnich datovych typu, jako je int nebo float.
Toto je totiz jedna z veci, ktera docela zprasila Javu. Tam primitivni datove typy existuji i se svymi operacemi, ale pokud s timto typem chci delat neco navic (napriklad prevest na retezec), musi se pouzit obalujici objekt.
(Java je v tomto ohledu docela zvlastni, neumoznuje sice pretezovat operatory, ale sama je vnitrne pretezuje, napriklad +. To je stejne jako Pascal, ten neumoznoval vytvorit funkci s promennym poctem parametru a sam mel zabudovany write a writeln).
Práce s byty, integery, floaty a poli nad těmito typy je velmi silně optimalizována - jak na úrovni objektové paměti, tak při jejich zpracovávání. Takže přestože primitivní typy ve Squeaku nejsou, výkonnostně se jim výše zmíněné typy minimálně blíží. Mimoto je celá řada operací kvůli rychlosti vykonávána primitivními metodami.
Optimalizace Squeaku jsou vůbec kapitola sama pro sebe. Např. díky tomu, že ifTrue: caseOf: apod. jsou optimalizovány na úrovni bytekódu pomocí skoků, je tyto metody možno dokonce úplně smazat bez toho, aby se to na funkčnosti prostředí nějak zásadně projevilo.
BTW: na této stránce je mimo jiné k dispozici jazyk ještě odvazovější než právě probíraný Smalltalk, a to SELF. Je to beztřídní jazyk, který poučku, že kromě objektu a posílání zpravy nepotřebuji už nic, dotáhl do naprosté/zběsilé čistoty. Já osobně sem bohužel v selfu ještě nic neudělal (i když asi dvakrát sem jej pustil ve škole) a to především proto, že vývoj selfu je uzavřen v SUNu (není tak dynamický jako u Squeaku) a navíc je jenom na platformy k nímž český programátor moc často nesedá (tedy MacOS a SPARC se Solarisem).
Každopádně zajímavý odkaz - akorát jsou ty články už hodně odborné.
Mno, zprasila.. uvedom si, ze Java byla puvodne delana pro pidipocitadla, a ta by objektovy overhead pravdepodobne neutahla. A ono i dneska maji imho sve opodstatneni, prece jen stale jsou lide, kteri se snazi, aby jim aplikace behaly co nejrychleji a nezraly vic pameti, nez je nutne.. ;)
Co se operatoru tyce, + neni napriklad, + (spolu s +=) je jedina vyjimka. Samozrejme ze to tam vubec dat nemuseli, a programatori dbali cistoty by meli zajiste radost. Na druhou stranu by to nepotesilo ty, ktere nebavi skladat stringy prez append().append().append().append().append().append() ...
No, ja osobne pisu vetsinu aplikaci v C/C++, a dost dbam na pametove a rychlostni parametry programu.
Prave proto jsem se ptal, jak je udelana optimalizace zakladnich objektovych typu ve SmallTalku, kdyz v Jave existuji pravdepodobne kvuli rychlosti primitivni datove typy a operatory. Mimochodem, v Jave jde o vsechno jine, nez o rychlost a male naroky na pamet :-(.
btw, pro spojovani retezcu se snad daji pouzit i dalsi paznaky, nemusi to byt zrovna plus. Java spoustu paznaku, narozdil od C/C++ nepouziva.
Jen poznamenávám, že ve Smalltalku se konkatenují řetězce (ale dokonce kolekce obecně) pomocí zprávy , (čárka). Tedy stejně jako věty v souvětí :-).
Např: 'ahoj', 'světe ', obj asString, '!'.
Jediné dva možné způsoby změny toku řízení programu ve Smalltalku jsou zavolání zprávy a návrat ze zpracování zprávy. Smalltalk nemá ani podmíněné skoky, natož nepodmíněné. Používá je pouze bytekód.
Aby to nebylo tak jednoduché, tak si můžete zkusit třeba:
