|Well some really interesting discussions :) ... I tend to agree with Leo's approach which extends type() without breaking it by adding a 2nd return value derived from __type or whatever from the metatable.|
For those saying "well, all you have to do is implement XXX" yes you are correct about how it can be done (there are dozens of ways). My point really was that the ability to project "metatype" information for userdata and tables is, imho, something that should be part of the standard base language. Such a facility is part of the basic contract between suppliers and consumers of objects, and so transcends individual local designs. Just like tostring() can be extended via the __tostring metafunction, so the type() function can be extended. This way, no new design pattern need be introduced, and Lua stays implementation neutral ... what is standardized is the contract BETWEEN the consumer and the supplier of type data.
As for extending type() versus some form of predicate, my feeling is that a predicate model belongs above the core layer; just like Lua does not have one baked-in object syntax, but instead provides the building blocks for many different OO paradigms, so the type() mechanism should be above any one paradigm. After all, any predicate system can really be built on top of an extended (two return value) type() function plus a conventionalized use of the second return value (string parsing etc etc).
On May 31, 2012, at 5:37 PM, Leo Razoumov wrote: