<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Dealing with asynchronous events, part 1</title>
	<atom:link href="http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/feed/" rel="self" type="application/rss+xml" />
	<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/</link>
	<description>music, technology, interfaces, people</description>
	<lastBuildDate>Mon, 19 Oct 2009 16:37:14 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: AS3 programming 101 for C/C++ coders - Geeky Derek</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-282773</link>
		<dc:creator>AS3 programming 101 for C/C++ coders - Geeky Derek</dc:creator>
		<pubDate>Sun, 24 May 2009 07:05:28 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-282773</guid>
		<description>[...] of articles covering the issues of &#8220;Dealing with asynchronous events&#8221;. So far, he has Part 1, Part 2, and Part 3 available. I strongly recommend reading these articles. They provide a lot of [...]</description>
		<content:encoded><![CDATA[<p>[...] of articles covering the issues of &#8220;Dealing with asynchronous events&#8221;. So far, he has Part 1, Part 2, and Part 3 available. I strongly recommend reading these articles. They provide a lot of [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: veeky学习笔记&#187; Blog 存档 &#187; 如何处理异步事件（第一部分）</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-97300</link>
		<dc:creator>veeky学习笔记&#187; Blog 存档 &#187; 如何处理异步事件（第一部分）</dc:creator>
		<pubDate>Fri, 23 Nov 2007 14:21:39 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-97300</guid>
		<description>[...] 原文地址：http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/ [...]</description>
		<content:encoded><![CDATA[<p>[...] 原文地址：http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/ [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Florecista&#8217;s Weblog</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-55251</link>
		<dc:creator>Florecista&#8217;s Weblog</dc:creator>
		<pubDate>Mon, 10 Sep 2007 05:40:59 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-55251</guid>
		<description>[...] Dealing with asynchronous events, part 1 [...]</description>
		<content:encoded><![CDATA[<p>[...] Dealing with asynchronous events, part 1 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kuwamoto.org &#187; Blog Archive &#187; Asynchronous calls explained</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-21210</link>
		<dc:creator>kuwamoto.org &#187; Blog Archive &#187; Asynchronous calls explained</dc:creator>
		<pubDate>Wed, 25 Apr 2007 17:23:48 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-21210</guid>
		<description>[...] Note that this is a more basic (and common?) case than the stuff I was talking about earlier. For more advanced solutions, see here, here and here. From: XXXX@XXXXXXXXX [...]</description>
		<content:encoded><![CDATA[<p>[...] Note that this is a more basic (and common?) case than the stuff I was talking about earlier. For more advanced solutions, see here, here and here. From: XXXX@XXXXXXXXX [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kuwamoto.org &#187; Blog Archive &#187; Dealing with asynchronous events, part 2</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-482</link>
		<dc:creator>kuwamoto.org &#187; Blog Archive &#187; Dealing with asynchronous events, part 2</dc:creator>
		<pubDate>Tue, 16 May 2006 19:02:17 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-482</guid>
		<description>[...] about &#124; contact     &#171; Dealing with asynchronous events, part 1 &#160;   16May2006 [...]</description>
		<content:encoded><![CDATA[<p>[...] about | contact     &laquo; Dealing with asynchronous events, part 1 &nbsp;   16May2006 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-481</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Tue, 16 May 2006 16:26:20 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-481</guid>
		<description>Thanks for the clarification, that helps. Regarding Function::call(), I thought that was the case, I was just having trouble because I always use apply() and also wasn&#039;t sure if maybe things had changed in AS3.

Maybe just changing the code to var callObject : Object = event.call; would help clarify a bit.

Thanks again,
Ben</description>
		<content:encoded><![CDATA[<p>Thanks for the clarification, that helps. Regarding Function::call(), I thought that was the case, I was just having trouble because I always use apply() and also wasn&#8217;t sure if maybe things had changed in AS3.</p>
<p>Maybe just changing the code to var callObject : Object = event.call; would help clarify a bit.</p>
<p>Thanks again,<br />
Ben</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sho</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-480</link>
		<dc:creator>Sho</dc:creator>
		<pubDate>Tue, 16 May 2006 15:58:48 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-480</guid>
		<description>Great questions, Ben.

It would be clearer if we could reverse the order of the two lines of code above, but there is no way to do that because the first line is the one that generates the call object.

As it turns out, there is no way that the return can arrive before the var is added, because all ActionScript code executes in a single thread. 

For example, let&#039;s suppose that you make an HTTP request in response to someone clicking on a button. All the lines of code for my click handler are guaranteed to execute before my result handler is called.

public function onClick(event: Event) : void
{
&#160;&#160;&#160;&#160;myService.addEventListener(&quot;result&quot;, onResult);
&#160;&#160;&#160;&#160;myService.send();
    
&#160;&#160;&#160;&#160;callFunctionOne();
&#160;&#160;&#160;&#160;callFunctionTwo();

&#160;&#160;&#160;&#160;// ...

&#160;&#160;&#160;&#160;callFunctionOneMillion();

&#160;&#160;&#160;&#160;// At this point, my click handler is done, and
&#160;&#160;&#160;&#160;// control goes back to the event loop. The next
&#160;&#160;&#160;&#160;// thing that will happen is that my result
&#160;&#160;&#160;&#160;// handler will be called.
}


As for the handler.call(xxx), this is an example of confusing naming.
&lt;ol&gt;
&lt;li&gt;When the result handler of an RPC service is called, it gets a result event which has a field called &quot;call&quot;. This is the object that was returned to you when the original call was made.
&lt;li&gt;In our own code, we are putting a handler on the call object which is a function object.
&lt;li&gt;There are two ways to call any function object. The first way is just to use parentheses like this: myFunctionObject(arg1, arg2).
&lt;li&gt;The second way is to use a method called &quot;call&quot; which every function object has. You use it like this: myFunctionObject.call(thisObject, arg1, arg2).
&lt;li&gt;The benefit of using the second way is that you get to manually specify what object should be used for the &quot;this&quot; object when making the call.
&lt;/ol&gt;

*whew* This is all a bit confusing (which is why I wrote the post in the first place). I think I may need to clarify a bit more in a followup post.</description>
		<content:encoded><![CDATA[<p>Great questions, Ben.</p>
<p>It would be clearer if we could reverse the order of the two lines of code above, but there is no way to do that because the first line is the one that generates the call object.</p>
<p>As it turns out, there is no way that the return can arrive before the var is added, because all ActionScript code executes in a single thread. </p>
<p>For example, let&#8217;s suppose that you make an HTTP request in response to someone clicking on a button. All the lines of code for my click handler are guaranteed to execute before my result handler is called.</p>
<p>public function onClick(event: Event) : void<br />
{<br />
&nbsp;&nbsp;&nbsp;&nbsp;myService.addEventListener(&#8221;result&#8221;, onResult);<br />
&nbsp;&nbsp;&nbsp;&nbsp;myService.send();</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;callFunctionOne();<br />
&nbsp;&nbsp;&nbsp;&nbsp;callFunctionTwo();</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;// &#8230;</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;callFunctionOneMillion();</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;// At this point, my click handler is done, and<br />
&nbsp;&nbsp;&nbsp;&nbsp;// control goes back to the event loop. The next<br />
&nbsp;&nbsp;&nbsp;&nbsp;// thing that will happen is that my result<br />
&nbsp;&nbsp;&nbsp;&nbsp;// handler will be called.<br />
}</p>
<p>As for the handler.call(xxx), this is an example of confusing naming.</p>
<ol>
<li>When the result handler of an RPC service is called, it gets a result event which has a field called &#8220;call&#8221;. This is the object that was returned to you when the original call was made.
</li>
<li>In our own code, we are putting a handler on the call object which is a function object.
</li>
<li>There are two ways to call any function object. The first way is just to use parentheses like this: myFunctionObject(arg1, arg2).
</li>
<li>The second way is to use a method called &#8220;call&#8221; which every function object has. You use it like this: myFunctionObject.call(thisObject, arg1, arg2).
</li>
<li>The benefit of using the second way is that you get to manually specify what object should be used for the &#8220;this&#8221; object when making the call.
</li>
</ol>
<p>*whew* This is all a bit confusing (which is why I wrote the post in the first place). I think I may need to clarify a bit more in a followup post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben</title>
		<link>http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/comment-page-1/#comment-479</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Tue, 16 May 2006 15:13:15 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2006/05/16/dealing-with-asynchronous-events-part-1/#comment-479</guid>
		<description>Hi Sho, great article, I am just a bit confused by the order of these statements:

call = myService.send();
call.handler = getAlbumInfoResult;

Shouldn&#039;t you assign the vars to the call object before sending? Even though its probably unlikely (impossible?) that the return would arrive before the var was added, it reminds me of the practice of defining your onLoad method before calling load() back in the LoadVars days.

I am also hazy on handler.call(null, event); Is that the call object or a method named call? Could you clarify a bit?

Thanks!</description>
		<content:encoded><![CDATA[<p>Hi Sho, great article, I am just a bit confused by the order of these statements:</p>
<p>call = myService.send();<br />
call.handler = getAlbumInfoResult;</p>
<p>Shouldn&#8217;t you assign the vars to the call object before sending? Even though its probably unlikely (impossible?) that the return would arrive before the var was added, it reminds me of the practice of defining your onLoad method before calling load() back in the LoadVars days.</p>
<p>I am also hazy on handler.call(null, event); Is that the call object or a method named call? Could you clarify a bit?</p>
<p>Thanks!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
