S, Philippe Marschall piše:
On 07/01/2011 12:47 PM, Janko Mivšek wrote:
S, Julian Fitzell piše:
2011/6/30 Janko Mivšek <janko.mivsek@eranova.si
Whole point is that this is a non-blocking code, in contrast to continuation based approach like in Seaside, where similar code would block and wait until dialog component returns answer.
Janko, what are you talking about? If it's not blocking, it's just a callback. Of course Seaside can do the same thing: you just use #show:onAnswer:.
Isn't the whole point of Seaside and continuations to enable worklow like in below example from the HPI Seaside tutorial? This code is blocking until the call: returns, isn't that so?
From HPI tutorial [1], chapter 5-Forms, figure 5-2 :
(self call: self taskEditor) ifTrue: [aTask copyFrom: self taskEditor task]
Text bellow: "Even better, Seaside remembers the position in your code and runs it from there again, after the called component finished. This means, #call: blocks your current component, that is your callback evaluation, waits for the called component to be finished, and afterwards goes on with your callback. "
Yes, but continuations don't block a Process. All they do is allow you to write code that is more readable.
Yes, technically it doesn't block that process because it must return something to the browser, but method execution actually blocks on that point. This blocking is not as hard as blocking like on long I/O, but it is still. While on the other side a non-blocking style continues execution of that method instead. Here is the point, and main diffenrec of blocking vs. non-blocking styles.
Instead of
self call: self taskEditor [ :value | value ifTrue: [ aTask copyFrom: self taskEditor task ] ]
you can write
(self call: self taskEditor) ifTrue: [aTask copyFrom: self taskEditor task]
There is no Process in the background waiting or anything.
In this simple case the benefit may not be that obvious but look at the case with only two steps.
first := self askForFirstObject. second := self askForSecondObject. (first aSelector: second) ifTrue: [ self something ] ifFalse: [ self somethingElse ]
Asynchronous way would be something like: self askForFirstObject onAnswerDo: [:first | self askForSecondObject onAnswerDo: [:second | (first aSelector: second) ifTrue: [self something] ifFalse: [self somethingElse] ] ] This surely looks less nice than your example but it is closer to event driven nature of browser and web apps. And because such workflow is actually rare, it is IMHO not worth such a big expense in framework complexity. Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si