On Thu, 24 Dec 2020 at 22:23,
frank@kastenholz.org < frank@kastenholz.org> wrote:
The Principle of Least Astonishment leads one to the position that type() ought not change in a way that is not backwardly compatible. One could make “newtype()” or, perhaps, have type() return two values (one of the existing values plus, optionally, the __name
field from the meta table)
That said, I do like the idea in principle & have done hacks similar to those described
In Ravi I added a new function that does this. I agree that leaving
the current type() function unchanged is better.
Regards
Definitely with the “don’t break existing type” folks.
I’ve also implemented type replacements to deal with custom objects in the past. I think a generic form of math.type() would be nice (better than adding table.type). Eg. Something
like “subtype()” that would incorporate math.type() as well as a meta-method/field to detect a type.
Alternatively extend type() in a compatible way with a second parameter to indicate you want the sub-type.
My 2cts
Thijs
|
