Re: minisphere 1.0.5
Reply #248 –
Also, I couldn't help but notice that the error displayed was simply "not boolean" - it didn't tell me what variable exactly it was having trouble with. While that was no issue whatsoever for my simple code, imagine it happening on a more complex line.
A bit of background on that. Here's what an API function looks like internally:
static duk_ret_t
js_SetPersonVisible(duk_context* ctx)
{
const char* name = duk_require_string(ctx, 0);
bool is_visible = duk_require_boolean(ctx, 1);
person_t* person;
if ((person = find_person(name)) == NULL)
duk_error_ni(ctx, -1, DUK_ERR_REFERENCE_ERROR, "SetPersonVisible(): Person '%s' doesn't exist", name);
person->is_visible = is_visible;
return 0;
}
duk_require_*() is shorthand for "get the value at this location on stack, but if it's not the type I'm looking for, throw an exception". It's very convenient, and keeps the code size down. But normally you don't even get a filename and line number for such errors: the only reason you do in minisphere is because I manually pull it from the call stack. Otherwise you'd just get a completely useless bare "not boolean" error.
I could fix it, of course, but that would require a bunch of extra conditional checks in every single API function, which really puts me off. Go look at the Sphere source sometime: For a lot of API calls, half the function is argument checking (which, mind you, doesn't really make sense since it still ends up type-coercing 90% of what you throw at it anyway; Spidermonkey is a ridiculously verbose API), and I'd prefer to avoid that here. The "mini" in minisphere is really about the code size more than anything; the fact that the engine itself takes up less space than Sphere 1.5 is just icing on the cake.