[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: unified methods
- From: "Peter Prade" <prade@...>
- Date: Thu, 29 Nov 2001 10:38:12 +0100
> >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):
if not recognized(o) then
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
so when you write
and o isn't registered with the new unified methods,
it is still expanded to:
this results in:
which is equal to:
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.