Subj : Re: JS_NewObject To : Jochen Stier From : Brendan Eich Date : Mon Mar 29 2004 02:01 pm Jochen Stier wrote: > BTW, you did not understand my question.... I said No, I understood you exactly. >>With "internal class" I meant a C++ class for which I have created a >>corresponding JavaScript class using JS_DefineClass. Now I would like to > > instantiate an object of the > >>"internal class" from within the C++ code !!!!!!!!!!===> and not the > > JavaScript <==== !!!!!!!! Yes, I saw that and replied explicitly. I deleted some of your words when citing your message because they were assumed. Sorry if that made you think I misunderstood your words, but I did not, and what's more, nothing in what I wrote implies that I misunderstood. Please try reading what I wrote, not looking for missing words from your message in what I cited, as if they prove anything. Your messages are very badly wrapped, and I didn't want to cite more than I had to. > I am NOT creating a new object from within JavaScript. I am creating it > inside the C++ app and then pass it to a JavaScript as a parameter in the > call JS_CallFunction (or whatever the proper name of that function may be). > I am just wondering how I can let the GC know that a JSObjects exists and > when it can remove them. Passing a newborn as an argument protects it from GC. Returning it to the caller of the native (not scripted, I knew that and wrote accordingly last time) function also arranges to protect the return value till the caller stores the value somewhere. Again, the only issue is the newborn "pigeon-hole" problem: if you call JS_NewObject twice and then do something with the first object, it may have been GC'd. The solution is to use a local root such as *rval, set right after the successful JS_NewObject call, to protect the returned new object. And don't bother calling JS_NewObject if JS_IsConstructing(cx) -- just use the obj parameter passed into your native constructor. /be .