lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Пт 15.07.16 7:26, Coda Highland wrote:
On Thu, Jul 14, 2016 at 6:19 PM, Sergey Rozhenko <sergroj@gmail.com> wrote:
On Пт 15.07.16 2:57, Sean Conner wrote:
    Oh, so to clarify (kind of making the bigint library up):

         bi = require "bigint"

         x = bi.make(2^128) -- syntax issues but I want something
         y = bi.make(2^128) -- really really large

         t = {}
         t[x] = "booya!"
         print(t[y])
         booya!

In this case __key would help at all. With or without it you'd have to keep
a cache of these values, because it's needed to make __key return the same
object. So, it's easier to make bi.make return the same object for both
calls instead.
That's not true at all. bi.__key could return a Lua "number"-type
value when the value is representable without loss of precision or a
string otherwise. This would provide for the nice property of
"t[bi.make(100)] == t[100]" in addition to the "t[x] == t[y]" desired
in the example.

Oops, indeed, it's representable with a number. However, it's a half-solution. For unrepresentable numbers strings aren't a way to go, because they aren't numbers. Plus, using strings involves internal Lua cache anyway. Does Lua 5.3 actually allow __eq between number and userdata/table? The __key proposal certainly requires __eq to fire across different types for consistency.