Re: gjs review

["Havoc Pennington" <hp pobox com>]

Resending after adding my send address to the list

On Thu, Oct 16, 2008 at 8:40 AM, Havoc Pennington <hp pobox com> wrote:
> Hi,
>
> On Thu, Oct 16, 2008 at 6:29 AM, Alexander Larsson <alexl redhat com> wrote:
>> On Wed, 2008-10-15 at 13:31 -0400, Havoc Pennington wrote:
>>> Hi,
>>
>> I see you replied to the wrong copy. CC:ing language-bindings on the
>> reply. :)
>
> Are you sure you mailed language-bindings before? I don't see it in
> the archives and didn't get it. I do see this mail in the archives.
>
>> Oh, thats a completely different thing. GJsValue is a nice c-side view
>> of a jsval. Its automatically rooted, so you can easily handle it
>> however you want, and it lets you check what kind of js type the value
>> is, and if its an object/function/array/gobject-wrapper js value you can
>> do type specific operations on them (like setting a named property of an
>> object to another GJsValue).
>
> Sounds good.
>
>> Well, "window" is also a quite common variable name, so hogging it with
>> something that might not be useful is kinda weird. And if you want to
>> have this in your app, it should be easy to use the API to add it.
>
> I don't have strong feelings on this, we can take it out.
>
>> On the contrary, they are very useful for many apps, even if you don't
>> use threads. The main reason is that they can give you multiple global
>> objects. In fact, this is how Mozilla does it. Each window has its own
>> context and thus global object ("window" as discussed above). This imho
>> makes very much sense when scripting a document centric application.
>> You'd set the document being edited as the global, making it easy to
>> access document specific stuff.
>
> Another way to do this would be to do it like the gjs module system,
> which does the equivalent of:
>  with (moduleObject) {
>    // eval module script here
>  }
>
> i.e. sets the moduleObject as the scope chain, as an arg to
> JS_EvaluateScript. In other words you don't need a context just to get
> a new global object; you only need a context to get a new stack,
> afaik.
>
> I don't have objections to sharing the runtime among all contexts,
> though. I thought you were saying to have both a runtime and a context
> object, I didn't understand you were proposing to behind the scenes
> share the runtime. That sounds best-of-all-worlds to me since it
> remains a simple API but you can still have multiple contexts.
>
> Note that gjs already uses three JSContext to implement GjsContext.
> (There's a closure invocation context and a load context, in addition
> to the script eval context.) The "extra" JSContext would be
> per-runtime though, not per-context, if allowing multiple GjsContext.
>
>> I'm not sure exactly why its like that, but we don't have to ever call
>> JS_EvaluateScript() or JS_ExecuteScript() with any other scope than the
>> global one. But this whole area is kinda confusing and we should perhaps
>> research it a bit more...
>
> This only matters in C code really; should be transparent elsewhere
> (from JS code, only the scope chain is used, not the global on the
> context, so there's no way to mess it up). But the basic implication
> is that JS_GetGlobalObject may not return the object JS code would
> currently see as the global object.
>
> Havoc
>