Re: Type Metatables for Table and Userdata - Powerpatch

[spir <denis.spir@...>]

On 06/12/2012 02:17, Luiz Henrique de Figueiredo wrote:
> > So hang on, would this mean that, as a host app or module writer, I can no longer rely on this to work:
> >
> >    t = { 1,2,3 }
> >    print(t[2])
> >    -> 2
> >
> > if some other module or user script has gone and installed a ???clever??? type metatable?
>
> The problems of having *one* event handler for all values of each type
> led us to move from fallbacks to metatables. See section 6.8 of our HOPL
> paper: http://www.lua.org/doc/hopl.pdf

Has the following been considered: that the implementation first checks whether 
a table _itself_ holds a "metafield", before checking a possible mt? This would 
allow 2 options:
* individual table elements of a prog to have proper behaviour w/o needing a mt
  example: customize the display of a table 'present_time'
* tables with a common mt used as custom type to still be specialisable
  example: among specimens of 'Point', a few show in a distinct manner (each 
proper)

This would also make some things easier. First and mainly, explaining and 
understanding the feature without too deep meta & abstract reasoning (it's just 
frightening for many, I guess). Also, meta-meta levels when touching metatypes 
or other kinds of root objects may be easier to setup [1].

(As an aside, this would also justify the special format of metafield names, 
else when beeing on proper metatables there is no risk of accidental name clash, 
imo.)

However, this would make tables special compared to other types (eg strings 
cannot themselves hold metafields...).

Denis

[1] No meta-meta[-meta]-table... but for this issue, I may miss a point, too. 
Still, when trying to formalise even the simplest regular custom-type system 
(also for array-tables or such clearly defined uses of tables) I step on the 
issue of the root object and its own mt beeing apart, with the occasional "loop 
in gettable".