Subj : Re: updated jsgen (maybe rc1?) - beta 7
To   : netscape.public.mozilla.jseng
From : Brendan Eich <brendan@meer.net>
Date : Sun Jan 04 2004 11:40 pm

Marcello Bastea-Forte wrote:

>
>> This is quite like what XBL does.  
>
>
> How exactly do you mean?  Does XBL generate JavaScript classes based 
> on some xml?


Yes, precisely.  See http://www.mozilla.org/projects/xbl/xbl.html.

>
>> One small improvement: use JS_LookupProperty instead of 
>> JS_GetProperty if your global object class's getter does any 
>> computation -- Lookup retrieves the slot-cached value of the property 
>> without calling the getter. 
>
>
> I just looked up the JS_LookupProperty function, and it needs (instead 
> of const char *):
> index jsint Index number of the element to look up.


You're looking at JS_LookupElement -- look again ;-).

>
>> That's neither fish nor foul: better would be to avoid any dependence 
>> on JS_GetGlobalObject, or use only it, and insist that there be a 1:1 
>> relationship between JSContext and global object.  Mozilla's DOM does 
>> the latter, but it is heavier-weight than the former.
>
>
> Would you recommend one method over the other?


(Er, fowl, not foul.  Sleep-deprived, I am!)

I think it's best to avoid coupling to a context's global object.  That 
leads to dynamic scope pitfalls, possibly even security bugs (if you 
associate different global objects with different trust domains, and 
someone can cause evil code to run using a context whose global is in a 
victim domain, so that the evil script has its way with victim data in 
spite of security checks -- this sort of thing has been known to happen).

> For example, putting all the classes in a GUI JSObject*, and then 
> doing something like var win = new GUI.Window(320,240). (You can do 
> that in JS, right?)


Yes. That's a good approach, but not really related to the 
JS_GetGlobalObject usage question.  See below for the right fix.

> The only solution I can think of is to somehow get the object where 
> the class of the JSObject* is defined.
>
> That seems complicated and I'm not immediately sure how to do it.


You want some notion of "scope" that can be deduced from an object.  The 
way in JS (even ECMA has this, for function objects -- see the [[Scope]] 
internal property) is to walk up the parent chain from the object till 
you find an object with null parent.  That's the "global scope" for the 
object you started from, and that's the object in which class-named 
constructors or prototypes are defined by JS_InitClass.

> Besides the namespace thing, can you think of any reason to bother 
> doing it any way other than by requiring the 1:1 global/context 
> mapping?  (Can multiple contexts share the same global object?)


They could, but it would be either a waste of memory (superfluous 
contexts), or a multi-threaded embedding mistake where different threads 
contend to set and get variables in the same global object.

> Similarly, do you see a way to do the namespace thing while using the 
> JS_GetGlobalObject method?


The JS_GetGlobalObject API is a distraction here, I think.  Walk up the 
parent chain, thereby implementing static scoping; avoid dynamic scoping.

/be

.