Subj : Re: Equivalent of JS_InitClass for global object?
To   : netscape.public.mozilla.jseng
From : jjl@pobox.com (John J. Lee)
Date : Sat Aug 23 2003 05:36 pm

Your reply got my mental gears turning on a number of issues, thanks.

One thing I don't understand: The JS_InitClass docs say:

| JS_InitClass builds a class structure, its object constructor, its
| prototype, its properties, and its methods. A class is an internal JS
| structure that is not exposed outside the JS engine. You can use a
| class, its properties, methods, and prototypes to build other objects
| that are exposed outside the engine.

which seems at first glancce to be in contradiction to your reply:

Brendan Eich <brendan@meer.net> writes:
[...]
> This will work -- you need not call JS_InitClass to use a JSClass
> struct.  You need to call JS_InitClass only if you have a class
> constructor, and want it to be named by the class name, and to have a
> class prototype; or, if you pass null for the constructor, to have the
> class name denote the class prototype object (e.g., Math).
[...]

because, if a class isn't exposed outside the API, why else would one
want to call JS_InitClass unless one is *required* to call it on *all*
JSClass structures?  I can't see anything in the docs for that
function that explicitly contradicts that assumption.  I guess the
answer is that though classes aren't themselves exposed, a
corresponding prototype object is -- and exposing that object is
JS_InitClass's purpose in life?  To me (a JS newbie), that purpose
isn't obvious from the JS_InitClass docs.

Anyway, after making some progress, I realised the whole idea of
defining the global object in Python was unnecessary: I can fake it by
just calling JS_DefineFunction repeatedly to bind both a Python
"window" object *and* all its methods to a trivial global object
defined from the C API.  Not fantastically elegant, perhaps, but it
should simplify my code.

I assume there's no reason to require "window" to *really* be the
global object?


John

.