Re: gjs review

[Alexander Larsson <alexl redhat com>]

On Thu, 2008-10-16 at 08:40 -0400, Havoc Pennington 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.

I think I did, but I don't see it either. *Shrug*

> > 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.

Using with is not quite the same though, it pushes moduleObject on the
scope chain, but it doesn't change the global object which is where
newly created global variables are set. So, its kinda confusing to use.
Although I guess you don't automatically get that behaviour with
JS_EvaluateScript unless you set parent on the object you set as scope
to the global object. Do you?

> 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.

Agreed then.

> 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 didn't get this part btw. GScript has only one extra JSContext, why do
you require two?