1
Vote

Hiding asynchronous behavior

description

Lambdas are definitely a way to make the programming model nicer. C# should make async property setting less painful, but I bet I could completely hide the async in Ruby ...
 
Brush.class_eval do
alias "actual_image=" "image="
def image=(url)
download(url) { |content| actual_image = content }
end
end
 

then you could do ...

 
brush.image = "http://..."
 
Of course this wouldn't work since the "content" would have to be converted to whatever "brush.image" expects, and everything between "{}" would actually be invoked on a different thread, so I'd have to put some locks in there since there's no guarantee "brush.image = foo" is thread-safe ... but you get the picture ;)
 
What's funnier is that there's one big synchronous operation in Silverlight that can still hang the UI thread: jitting. DLRConsole hangs the browser for like 10 seconds before starting up. I'd love it if Moonlight would JIT on a background thread. =) I'm trying to get the Silverlight guys to make that change, but no commitment yet. And you can still do synchronous downloading by using the HtmlBridge to get to the XmlHttpRequest object.
 
The only reason the limitation is there is because current browsers run <object> controls on the UI thread. Chrome is actually the best Silverlight browser IMO because it runs each <object> control in a different process, so any blocking calls won't hang the browser UI. =P Hopefully future browsers can adopt this behavior, then the need for async-only would go out the window.
 
What I figured could be done is that Silverlight could continue to
enforce a policy of no-asynchronous operations, like expecting:
    brush.Image = "http://..."

To work, but instead in those situations to always require that the
file is downloaded asynchronously and to force the developer to set any
properties in a callback, like:
    Download.Fetch ("http://...", x => MyBrush.Image = x);

comments