Re: String metatable and string.len

[Mason Bogue <scythe+lua@...>]

It would be weird to write code like (3.14 * x):sin(), wouldn't it?
You can set up metatables locally if you're embedding Lua. I think
that maybe this could be a good idea for threads, but not for other
types.

For arrays specifically:

function array(...)
   local a = {...}
   setmetatable(a, {__index = table})
   return a
end

One reason *not* to do this is that there are better array libraries
out there. Lua is a "glue" language, so it tends not to include
features in the core language that can be easily added by the user.
However, Lua is good at statically linking with lots of little
libraries that you just import whole and don't worry about dependency
management or anything. Libraries can be very short and still
efficient in pure Lua. If your use-case targets modern general-purpose
computers, this should work fine for you.

Unfortunately I think most Lua "stdlib" attempts tend to be too
ambitious and the creators "bite off more than they can chew". Nobody
wants to use a half-finished library. Lua Power (luapower.com) does an
okay job of accumulating various well-made libraries, although the
curated selection is... not curated enough, IMHO.


On Sun, Mar 22, 2020 at 9:45 PM Halalaluyafail3 <luigighiron@gmail.com> wrote:
>
> Strings have a metatable with __index set to the string library so you can call methods directly on strings. (e.g str:sub(1,2)) Is there any reason for this, and why is this only done for strings? Threads and numbers could implement this similarly to how strings do it. (so num:floor(), thread:resume(), etc) Even if it were to be implemented on threads and numbers, it would still feel somewhat inconsistent since tables wouldn't get a metatable. (because each table gets its own metatable)
>
> string.len exists, even though the length operator exists. Isn't it redundant to have a function to have a function which is equivalent to simply using the length operator? table.getn was deprecated and removed, but string.len wasn't. Curious as to why string.len isn't removed by now.