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 :-))

ST je silne typovany, ale typovany v case behu. Tyto dveveci byvaji zamenovany.

Neni pravda, ze by objekt zpravu, ktere nerozumi ignoroval (tedy pokud to neni jeho cilem). Pokud zpravu nedokaze zpracovat, posle misto ni zpravu #doesNotUnderstand, ktera byva zdedena z Object a standardne generuje MessageNotUnderstoodError.

O typu se ve Smalltalku mluvi dost tezko, pokud typem rozumime nejakou domenu hodnot a operaci s nimi. V nejakem kontextu nam staci, aby objekt rozumel prave jedne zprave a nezalezi na tom jake je tridy a co dalsiho umi.

Z predchoziho prispevku bych si dovolil podotknout, ze objektu lze zmenit tridu prakticky bez jeho vedomi (#changeClassTo:), ackoliv se technicky da pouzit jen malokdy. A nenapada me situace, kdy by to bylo potreba.

Ve Squeaku se tato metoda jmenuje primitiveChangeClassTo: a její použití má řadu omezení. Tento způsob považuji za poměrně nestandardní. Navíc i tuto zprávu posíláte konvertovanému objektu, takže na to, že se ho někdo snaží překonvertovat, může dle libosti reagovat. Ve Squeaku je služeb této metody využito jen jednou a to v případě, že se Inspector snaží vytvořit sám sebe pod jinou třídou vhodnější pro nahlížení nad daným objektem.

Samozrejme uznavam, ze jde o metodu krajne nestandardni, nicmene neskodi o ni vedet. Nevim, jak je to udelane ve Squeaku, ale v teto souvislosti by bylo vhodnejsi mluvit o zprave #adoptInstance:, ktera se posila tride, aby se stala tridou nejakeho objektu. Samozrejme ma celou radu omezeni a lze ji pouzit jen ve velmi malo pripadech.

O jejim pouziti se nechci prit, pouziva se vicemene pri refaktoringu a pro podporu systemovych nastroju, rozhodne nejde o beznou soucast aplikaci.

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()) ?

Primitiva pro naslouchání na soketu je neblokující, tzn. že vždy je třeba existenci nového připojení cyklicky testovat. Viz např. ConnectionQueue>>listenLoop. V příkladu uvedeném v článku je použití ConnectionQueue skoro zbytečné, protože ta se používá především v situacích, kdy všechna spojení obsluhujeme jedno za druhým v jednom procesu. Místo Processor yield by šlo použít i třídu Delay.

Pro smalltalkovskou architekturu vlastně ani není jiné cesty, protože primitivy se provádí atomicky. Pokud by primitiva pro naslouchání na soketu byla blokující, došlo by k zablokování všech procesů.

Primitiva samozrejme nesmi byt blokujici, ale cekaci smycka muze mimo uvedenych moznosti taky cekat na semafor, kteremu ve vhodny okamzik posle signal primo VM.