Alec Flett wrote:
> I just looked at nsIScriptcontext, and I really like the idea of putting
> this there.. I guess it's up to jst, if he wants to put varargs stuff
> into nsIScriptContext.
>
> I've explored this issue a fair amount though, trying to get around
> using varargs - the problem is really that there's no way to call
> JS_PushArguments or JS_PushArgumentsVA with a list of arguments
> generated at runtime.. this means that we don't have any way to
> implement a method like
>
> NS_IMETHOD CallNativeWithArgs(nsJSCallerCallback *aCallback, void
> *aClosure, PRInt32 aArgc, void **aArgv)
> or perhaps
> NS_IMETHOD CallNativeWithArgs(nsJSCallerCallback *aCallback, void
> *aClosure, const char * aFormatStr, void **aArgv)
You need a format string, or something like it, in order to push the
right jsvals.
> where aArgv is an array of arguments, and have it processed
> appropriately by JS_PushArguments[VA].
>
> It's also a tremendous amount of work to simulate what
> JS_PushArguments[VA] does .. our one other option might be to factor out
> the argument formatting from JS_PushArguments[VA] and create a new
> function:
> JS_PushArgumentsList(const char *formatString, void *argv)
We could do that. Bug me if it would help. When you and I talked (a
while ago), it sounded like you were going to use
js_AllocStack/js_FreeStack and do the converting (IntArg, StringArg,
etc.) and pushing yourself. That's more verbose, more calling code
footprint, than the varargs approach. Passing a void **argv also
requires time and space to set up the input buffer, which is then copied.
Minimal change argues in favor of stdarg-based methods. Are we sure we
can wedge a stdarg-based method into a non-scriptable interface on all
platforms? If so, let's do that and avoid any JS_PushArgumentList bloat.
/be
>
>
> or something...
>
> Alec
>
>
> John Bandhauer wrote:
>
>> John Bandhauer wrote:
>>
>>> I'm not too concerned about where it goes. Is appshell a general
>>> enough place? Putting it in xpconnect is ok with some cleanup and
>>> changes to conform to the local traditions.
>>
>> Then again, maybe this should just be a new method on
>> nsIScriptContext/nsJSContext? Then you wouldn't even need to add
>> any new files. Would we want to saddle it with this varargs
>> method? It is already plenty ugly :)
>>
>> John.
>
