Subj : Re: Calling non-existent object function crashes engine
To   : Brendan Eich
From : Syd Logan
Date : Tue Sep 06 2005 12:48 am

Good questions.

Fun? Undeniably so.

The answer to the reinventing the wheel issue is maybe not so easy. And 
I am glad you asked the question. While I clearly see how NSPR and the 
JS engine offer nice, seemingly lightweight, self contained solutions, 
largely independent of mozilla (no nsIThis or nsIThat couplings), I 
don't quite get that feeling about xpconnect. Perhaps I just haven't 
stumbled on the right docs, or spent enough time peering at the code in 
js/src/xpconnect. Perhaps I need someone to help me see thru that fog (I 
really appreciated the js embedding doc you wrote Brendan, as well as 
the JS API docs).

I actually like how things are going with my approach so far, and I 
think there is room for both educating my readers on xpconnect, while 
also enlightening them to the fact that you can, if need be, do things 
in a different way. Surely the JS embedding engine isn't tied to the hip 
with xpconnect, and perhaps people would prefer to come up with a 
custom, more specific solution to the problem -- I intend to show them 
how that can be done.

syd

> Syd Logan wrote:
> 
>>>>>     JSClass objectClass = {
>>>>>         name.c_str(), JSCLASS_NEW_RESOLVE,
>>>>>         JS_PropertyStub,  JS_PropertyStub,
>>>>>         JS_PropertyStub,  JS_PropertyStub,
>>>>>         JS_EnumerateStub,  JS_ResolveStub,
> 
> 
> 
> I should have seen that JSCLASS_NEW_RESOLVE flag -- it changes how the 
> resolve hook is called, so JS_ResolveStub won't do at all, as John 
> pointed out.
> 
> I'll also agree emphatically with John that you are reinventing a wheel 
> here.  It may be fun.  You may be able to simplify the problem slightly 
> so as to simplify the reinvented solution a bit. But is it worth it not 
> to use XPCOM/XPConnect?
> 
> /be

.