[whatwg] Passing more than JSON data to workers

On 16 Dec 2009, at 13:47, Boris Zbarsky wrote:
> 
> On 12/16/09 1:27 PM, Jan Fabry wrote:
>>> function setFoo(val) { foo = val; }
>>> function getFoo() { return foo; }
> ...
>> After the second postMessage, the worker receives a new object, also a function, bound to a variable with the value 1.
> 
> What if getFoo were:
> 
>   function getFoo() { return this["foo"]; }
> 
> What if it were:
> 
>   function getFoo() { return this["fo" + "o"]; }
> 
> What about:
> 
>   var o = "o";
>   function getFoo() { return this["fo" + o]; }
> 
> ?

These three functions are equivalent to me. They will return this.foo, but 'this' is a keyword that refers to the scope the function is called in, it is not a regular variable.

Ignoring web workers, say we execute the following in a current Javascript environment:

getFoo.call({'foo': 'otherFoo'})

will return 'otherFoo'. 

getFoo.call({})

will return undefined.

If no scope is given, the global scope is used, and then it depends on the state of the variables on the worker side. If no 'foo' variable has been defined, it will return undefined.

> Maybe a better question is: What problem are you trying to solve?

I do not have a concrete problem now, but I am imaging libraries that currently use the nice features of Javascript, like functions being passed around as parameters, to delegate certain behavior to code written by users of their libraries. It took a while before the good parts of Javascript were discovered, and we are happy that they exist, so I think we should try to make web workers as good as possible too.

Much of this can probably be emulated, but, as Simon said in a related discussion, regarding data: urls:
[ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023195.html ]

"In particular, though, I suspect that people will work around this  
limitation by one of the means we've come up with so far, or maybe people  
with come up with even uglier workarounds. If we remove the limitation,  
people will have no reason to come up with ugly hacks but instead use the  
obvious supported way to do it, and it will be easier to debug and follow  
code."

(btw Jonathan, I think the last reply in that discussion was from Ian: [ http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/023588.html ])


When this discussion is over, I want to know why it is not implemented: because it leads to some undefinable situations, because it would be too complicated to teach to developers what does and what doesn't work, or because it is too difficult for implementors to do it right. But when I look at what browsers can do these days, I have not yet seen a limit to the intelligence of their developers :-)

> 
> -Boris

Thank you for all your insightful comments,

Jan Fabry

(If this reply appears out of context, it is because I follow the list using the digests. Sorry about that.)

Received on Thursday, 17 December 2009 00:34:21 UTC