lua-users home
lua-l archive

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



On 19/07/16 08:55 PM, Sean Conner wrote:


   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?).
No, they didn't ask for this. But this would be less work for them and it'd also benefit other Lua users. Yes, I could just make a patch, but that'd be effectively the same thing they did: it doesn't benefit your average Lua user, it only benefits the Lua users who look for it. 

   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.
There's no overhead of checking the metatable because you wouldn't be checking the metatable, you'd be checking for the presence of __key.
It'd be tagged, just like how __gc is tagged; it would be much faster than checking the metatable. 

   -spc (We don't even know the overhead of the explicit method, again,
	because there's nothing to measure)
In theory, a Lua->C function call is way more expensive than a C if statement. 

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.