Názory k článku Squeak: návrat do budoucnosti (17)

pripada mi ze autor se v ramci celeho serialu snazi navazet do ostatnich jazyku s poukazovanim na jejich nedostatky aniz by ukazal poradne jak to zvlada smalltalk - viz ta posledni narazka na dynamicke stranky. osobne me by to velice zajimalo po zkusenostech s cistym cgi, perlem, php, jsp, asp.net - kazdy z techto jazyku (technologii) ma neco do sebe, ale zda se mi nekorektni napsat jen, ze si tam vyssi silne typove jazyky ani neskrknou. ano tyto jazyky maji svoje nevyhody (treba silnou typovost), ale i taky vyhody (treba silnou typovost) :-)) a tak by slo psat do aleluja. zalezi hodne na uhlu pohledu a pouziti.

Ta poznámka o neškrtnutí si se týkala samozřejmě pouze přístupu, kdy se lze na bázi prototypování a dynamické dědičnosti úplně obejít bez nutnosti vytvářet pro každou stránku vlastní třídu a přitom se držet stále čistě objektového přístupu. To je skutečně už mimo síly staticky typovaných jazyků a při pokusu něco takového v nich vytvořit byste se pravděpodobně utopili v záplavě maker a navíc byste se stejně statické typové kontroly museli vzdát.

PHP je slabe typovany jazyk.

samozrejme perl taky :-) silnou typovost sem uvedl jako jeden z prikladu, nevyhod nekterych z tech jazyku (technologii) oproti smalltalku - ale neslovickarme.

Smalltalk je přísně typovaný jazyk. Standardními mechanismy nelze žádný objekt bez jeho vědomí překonvertovat na jiný typ.

teda nejsem expert na smalltalk, ale pripada me, ze skutecnost, ze objektu jde zaslat zprava a on pokud na ni zna odpoved tak reaguje, jinak ji ignoruje, me to pripada jako vlastnost slabe typovanych jazyku. na druhou stranu zase nekdo muze tvrdit, ze smalltalk je prunik mezi silne a slabe typovanyma jazykama :-))

Diky za tento dil ;-).

OldFrog.

K cemu je tam ten Processor yield ? Prijde mi, ze by se uplatnil jenom pri dost drsne zatezi, jenze pak by sam o sobe nic nevyresil, jenom by se to chovalo trochu jinak blbe. :-) (A tak jako tak mi to prijde jako zbytecnost u ukazkoveho prikladu.)

Dávat tento příkaz do nekonečných smyček běžících v separátních vláknech je, pokud to dává smysl, velmi dobrým zvykem a myslím si, že právě u ukázkového příkladu to rozhodně není na škodu.

Cílem nebylo zlepšit rozložení zátěže pouze toho serveru, ale Squeaku jako celku.

Tak ted tomu rozumim cim dal mene. Chcete snad rict, ze to getConnectionOrNil je "neblokujici", tzn. ze ta smycka tam busy-waituje?

Jde o to, že to vlákno běží na nepoužívanější prioritě, jakou má např. většina GUI a celá řada dalších procesů. Nejedná se o kriticky důležitý proces, protože nová připojení odchytává vlákno s vyšší prioritou. Jestliže při předání procesoru tomuto vláknu nebylo zjištěno nové připojení, je velmi pravděpodobné, že v nejbližší době nové připojení zjištěno rovněž nebude a nemá tedy cenu to opět testovat a je lépe předat procesor ostatním vláknům, která jej snad využijí efektivněji. I v případě, že je nové připojení indikováno, bude díky uvolnění procesoru zpracováno dříve, než kdybychom metodu yield nepoužili.

Ano, tomuhle samozrejme rozumim za predpokladu (ktery je tedy zrejme spravny), ze getConnectionOrNil se okamzite vraci, at uz nejake spojeni je, nebo neni. Z toho ovsem IMHO vyplyva, ze tenhle thread tady busy-waituje, takze zbytecne zere CPU cas. Ten yield to sice samozrejme vylepsi, ale porad nic extra. To neexistuje lepsi reseni, kdy proste pockam na prichozi spojeni (ala accept(), nebo neco jako select()) ?