RE: language-bindings Digest, Vol 35, Issue 2, Subscribe

[SAEID BESYARFARD <besy helloworld hotmail com>]

Subscribe
----------------------------------------
> From: language-bindings-request gnome org
> Subject: language-bindings Digest, Vol 35, Issue 2
> To: language-bindings gnome org
> Date: Fri, 17 Oct 2008 12:00:24 +0000
> 
> Send language-bindings mailing list submissions to
> 	language-bindings gnome org
> 
> 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
> 	language-bindings-request gnome org
> 
> You can reach the person managing the list at
> 	language-bindings-owner gnome org
> 
> 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: language-bindings gnome org, lucasr gnome org
> 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: language-bindings gnome org, lucasr gnome org
> 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  language-bindings gnome org
> 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/