Re: C++ binding: arg errors

[Glenn Maynard <glenn@...>]

On Sat, Oct 07, 2006 at 04:28:51PM +1000, Nick Gammon wrote:
> However you are right, they report errors differently. Pulling "foo"  
> off the stack does indeed result in strange error messages, but not  
> pulling it means that when I want argument 1, I have to really ask  
> for argument 2. Somehow this seems strange to me, that if I ask for  
> argument 2, and it is in error, it reports argument 1 as being wrong.

I agree.  (Even if I didn't, I wouldn't change it, since it would make
every method of over 500 functions that takes parameters silently wrong,
so I'd have to review every one.)

> All I can suggest now is to leave the self on the stack, and instead  
> change things like luaL_checkstring (and so on) to use a stub  
> function that adds 1 to the requested argument.

I thought about that:

 - Every function that can affect the stack would need to be changed,
 and that's most of the API;
 - it'd need to handle negative offsets correctly;
 - only functions in this binding style can use this; other Lua code
 needs to access it normally.  That's inviting all kinds of confusion,
 much worse than args starting at 2 or having wrong error messages, I
 think;
 - I'd still have to change the whole codebase to do this.

> Unless there is a way of convincing Lua that once the "self"  
> parameter has been removed (with lua_remove) that it is not in fact  
> there any more.

I've only looked at the internals briefly, but it looks like the stack
can be moved up and down by changing L->base.  In principle, I'd
think it would be possible to move the stack up one, hiding the
first entry outside of the visible stack, and replace that value with
a sentinel (eg. an empty table).  Then, when luaL_argerror sees
namewhat == "method", it looks up past the top of the stack for that
table; if it sees it, it knows it's a method with no self, and handles
it accordingly.

That's gross, and I'm sure there are bits that won't work without
knowing more about the internals--but I don't have any other ideas.

(In principle, the sentinel value could be pushed after the self value.
That way, the value stays alive on the stack, so if you have data affected
by GC, you won't hit the problem described by Rici.)

-- 
Glenn Maynard