Re: [Feature Request?] __key

[Sean Conner <sean@...>]

It was thus said that the Great Soni L. once stated:
> 
> On 19/07/16 06:59 PM, Sean Conner wrote:

> >   No, I don't want "it would be nice to have this feature".  I want the
> >actual code that is currently failing for you, right now.  What is the
> >actual issue?  Because there are times when I suspect you are trying for a
> >theoretical purity in implementation of an idea, not an actual problem for
> >which there is what you want is the only solution (but that's just my 
> >take).
> 
> I didn't create it, and I don't have access to it, but one of the 
> LuaConf talks was about stored procedures.

  [ snip ]

> You can patch the VM to make this work right, and that's what the DB 
> guys did. However, that means they're locked onto a single patched VM 
> version, and upgrading/changing versions means writing a new patch. The 
> __key proposal would instead provide a stableish API so you could switch 
> Lua/VM versions without too much trouble ...
> 
> This isn't a "this would be nice to have" proposal, this is a "I wanna 
> help these people" proposal. They have a usecase for it, and it would be 
> useful for many of us as well. But I really just wanna help these people.

  Seriously?  Did they ask for this?  Did they think this was an issue?
Because if it's the talk I think it is (from the list at the LuaConf
website, the Lua stored procedure talk by Alex Scotti), then it sounds like
they were happy with Lua and modified it ("We extended the data types to
include all DB data types and added some extensions to declare variables
with types, allowing for a form of strong typing at runtime") to suite their
needs.

  *THIS* comes across as "this would be nice to have" to me.  It's not
*YOUR* problem nor *YOUR* code.  It's nice to want to help, but I think you
would be better served by *implemeting* your idea, making it a patch that
people can try out (maybe even the DB guys) and discuss (do the DB guys
think this would help them?).

  Okay, getting back to yet another point:

> Lua/VM versions without too much trouble, as most other extensions could 
> be trivially implemented through preprocessing (by replacing `load`) 
> (e.g. turning `x := (expr)`, the syntax for type-converting assignment, 
> into `x = typeconv(x, (expr))`). The only reason this __key thing can't 
> be done in preprocessing is because it would involve turning every 
> single `t[x]` into `t[tokey(x)]` which is (in theory) significantly 
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> slower than just checking for __key in the VM.
^^^^^^^^

  You don't know for sure.  In my opinion, there will probably be no
significant difference between

	t[tokey(x)]

and

	t[x] -- with __key metamethod override

since they are both doing the same work.  But I'm not 100% certain of that
because there's nothing to measure.  I could also see the __key method being
measurably slower because of the overhead of checking the metatable; whereas
with the explicit call, you only invoke the overhead on items that need
translating.  But again, I'm not 100% certain of that beacause there's
nothing to measure.

  -spc (We don't even know the overhead of the explicit method, again,
	because there's nothing to measure)