RE: unified methods

["Peter Prade" <prade@...>]

> >but why use another operator at all?
> >it should be easy to provide backward compatibility with
> >appropriate methods, or am i missing something? so you can stick
> >to . and :
>
> It would be possible to make the : operator first check myTable and then
> methods(myTable), but at the very least, you have the cost of the
> myTable hash lookup, which could be a waste of time.  To make the :
> operator just look at methods(myTable) would be bad, because it would
> break existing code, in addition to not allowing an implicit self to be
> passed through to a myTable function (although it's debatable how
> important that is).

i guess i was not clear enough...

i suggest to make the : operator just as in Sol (no additional cost):
o:f() becomes methods(o).f(o)

and then provide a methods() function that in the case it doesn't know
anything about the passed object, switches to "backward-compatibility-mode"
(her comes the additional cost):

function methods(o)
	if not recognized(o) then
		return proxy_table
	end
end

the proxy_table is a table with a tag_method set for gettable:

function gettable_event (table, index)
	return function(self,...) call(self[%index],arg) end
end

so when you write
	o:f(...)
and o isn't registered with the new unified methods,
it is still expanded to:
	gettable(o).f(o,...)
this results in:
	proxy_table.f(o,...)
which is equal to:
	call(o["f"],{...})

which is exactly what you want for backwards compatibility.

granted, there is an additional cost, but only for old code, and not too
bad, i think.

Cheers,
Peter