On 2010.01.04., at 17:07, Daryl Stultz wrote:
> On Mon, Jan 4, 2010 at 8:54 AM, Attila Szegedi <[email protected]> wrote:
>
>> As an implication, if you use a new top-level scope for every script
>> execution (which you normally do), you'll end up with the cache being
>> recreated on a per-scope basis. If you use a shared-prototype top-level
>> scope, you'll avoid this (but then you have to use shared-prototype
>> top-level scope pattern, which I generally dislike).
>>
>
> This page:
> https://developer.mozilla.org/En/Rhino_documentation/Scopes_and_Contexts
> under "Sharing Scopes" states "for our purposes it gives us an easy way to
> share a set of read-only variables across multiple scopes". Is this section
> describing the "shared-prototype top-level scope pattern" you dislike? Your
> drawbacks state it is mutable but the line I cited says "read-only".
>
> Perhaps you can describe how it is "non-standard". How would someone writing
> the JavaScript get tripped up by this?
Normally, it doesn't. I myself have a system that uses this approach that
churns over a million script executions per day and encounters no problems. The
problem is, you'll hardly be able to completely lock down the shared scope -
while you can not easily put anything into it, you can, say, have one script
extend or replace functions of standard objects (i.e. Array.push = function() {
... } - you get the idea) and have it be observed by all others. You can, of
course, go through the full reachable JS object graph in the shared scope by
recursively calling getIds() and then call ScriptableObject.seal() on every one
of them.
Then in turn, you'll have a problem if you (or users of your system) will
actually expect to be able to modify built-in objects (i.e. by adopting a JS
library that attempts to do it) and failing. Now, of course, you could
"install" that library into the shared scope by executing its function-defining
scripts in that scope, and that'll solve the problem. However, you then might
run into the problem of that library using "x" instead of "this.x" to refer to
some globally defined "x" - it'll fail if "x" is actually defined in the
individual non-shared scopes. Witness:
shared scope has these functions defined:
function getGlobalX() {
return x;
}
function getThisX() {
return this.x;
}
a script then runs against individual scope that has the shared scope as the
prototype:
var x = 1;
print(getThisX());
print(getGlobalX());
getThisX() will succeed, but getGlobalX() will fail. If you can, fix the
functions to use explicit "this." (or not rely on global identifiers - even
better). If you can not, then you need to turn on Rhino's "dynamic scopes"
feature, which introduces non-standard scoping resolution rules (as JS language
specification prescribes use of lexical scoping), and can then create subtle
bugs with libraries that use lexical scopes to implement private members.
So, yes, you can do it, and I'm not speaking against it, just making sure you
know the potential pitfalls - if they don't apply to your system, all the
better.
Attila.
--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com
>
> Thanks.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:[email protected]
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
