Subscribe ---------------------------------------- > From: [EMAIL PROTECTED] > Subject: language-bindings Digest, Vol 35, Issue 2 > To: [email protected] > Date: Fri, 17 Oct 2008 12:00:24 +0000 > > Send language-bindings mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.gnome.org/mailman/listinfo/language-bindings > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of language-bindings digest..." > > > Today's Topics: > > 1. Re: gjs review (Havoc Pennington) > 2. Re: gjs review (Alexander Larsson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Oct 2008 08:47:33 -0400 > From: "Havoc Pennington" > Subject: Re: gjs review > To: "Alexander Larsson" > Cc: [email protected], [EMAIL PROTECTED] > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Resending after adding my send address to the list > > On Thu, Oct 16, 2008 at 8:40 AM, Havoc Pennington wrote: >> Hi, >> >> On Thu, Oct 16, 2008 at 6:29 AM, Alexander Larsson 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 >> > > > ------------------------------ > > Message: 2 > Date: Fri, 17 Oct 2008 09:57:12 +0200 > From: Alexander Larsson > Subject: Re: gjs review > To: Havoc Pennington > Cc: [email protected], [EMAIL PROTECTED] > Message-ID: > Content-Type: text/plain > > On Thu, 2008-10-16 at 08:40 -0400, Havoc Pennington wrote: >> Hi, >> >> On Thu, Oct 16, 2008 at 6:29 AM, Alexander Larsson 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? > > > > > ------------------------------ > > _______________________________________________ > language-bindings mailing list [email protected] > http://mail.gnome.org/mailman/listinfo/language-bindings > > > End of language-bindings Digest, Vol 35, Issue 2 > ************************************************
_________________________________________________________________ Die neue Generation der Windows Live Services - jetzt downloaden! http://get.live.com/ _______________________________________________ language-bindings mailing list [email protected] http://mail.gnome.org/mailman/listinfo/language-bindings
