Is it necessary to put a none-closure function defination out of a method for lua jit?

xiangnanscu · 2016-08-09T10:09:52+00:00

Thanks.Will doOn Monday, August 8, 2016 at 10:53:18 AM UTC-7, Sudharsan R wrote:Hi, I wrote a kong plugin that does a simple URI rewrite. The function is exe...

Is it necessary to put a none-closure function defination out of a method for lua jit?

xiangnanscu

If I write a module `test.lua` like this:

local M = {}
local function caller(tbl, opts) 
    return tbl:new(opts)
end
function M.new(self, init)
    init = init or {}
    self.__index = self
    self.__call = caller
    return setmetatable(init, self)
end
return M

Will it better than this?

local M = {}
function M.new(self, init)
    init = init or {}
    self.__index = self
    self.__call = function (tbl, opts) return tbl:new(opts) end
    return setmetatable(init, self)
end
return M

If I use this module like this:

local instance = require"test":new{}

aapo.talvensaari

On Tuesday, 9 August 2016 05:09:52 UTC+3, 项楠 wrote:

If I write a module `test.lua` like this:
Will it better than this?

The first one is better. But I would write it like this:

local setmetatable = setmetatable
local M = {}
M.__index = M
function M:__call(init) 
  return self:new(init)
end
function M:new(init)
  return setmetatable(init or {}, self)
end
return M

One style difference though. I prefer ":" notation for instance function calls, and "." notation for module level function calls, e.g.:

I prefer:

local instance = require"test".new{}
instance:method()

Instead of:

local instance = require"test":new{}
instance:method()

xiangnanscu

Why first one is better? performance consideration?

在 2016年8月9日星期二 UTC+8下午3:12:46，Aapo Talvensaari写道：

On Tuesday, 9 August 2016 05:09:52 UTC+3, 项楠 wrote:
If I write a module `test.lua` like this:
Will it better than this?

The first one is better. But I would write it like this:

local setmetatable = setmetatable local M = {} M.__index = M function M:__call(init) return self:new(init) end function M:new(init) return setmetatable(init or {}, self) end return M

One style difference though. I prefer ":" notation for instance function calls, and "." notation for module level function calls, e.g.:

I prefer:

local instance = require"test".new{} instance:method()

Instead of:

local instance = require"test":new{} instance:method()

aapo.talvensaari

On Tuesday, 9 August 2016 13:30:41 UTC+3, 项楠 wrote:

Why first one is better? performance consideration?

Why create a new closure everytime when you are not even using anything that needs a closure (e.g. access to upvars)?

dsgnvictor

Did you mean require"test".new({}) ? Or I'm missing something obvious here ?

I prefer:

local instance = require"test".new{} instance:method()

Instead of:

local instance = require"test":new{} instance:method()

aapo.talvensaari

On Wednesday, 10 August 2016 16:28:12 UTC+3, Victor wrote:

Did you mean require"test".new({}) ? Or I'm missing something obvious here ?

Nope.

require"test".new({}) is equal to require"test".new{}

aka, they are the _same_,

dsgnvictor

Thank you Aapo.

Just one more thing. "." and ":" notations.
I created meta.lua with the sample you provided:

local setmetatable = setmetatable
local M = {}
M.__index = M
function M:__call(init) 
  return self:new(init)
end
function M:new(init)
  return setmetatable(init or {}, self)
end
return M

Then content_by_lua :

local instance = require"meta".new{ a="test" }
ngx.say(instance.a)

returns "nil"

But this:

local instance = require"meta":new{ a="test" }

works. Sends "test".

aapo.talvensaari

On Wednesday, 10 August 2016 20:07:20 UTC+3, Victor wrote:

Thank you Aapo.
Just one more thing. "." and ":" notations.
I created meta.lua with the sample you provided:

local setmetatable = setmetatable local M = {} M.__index = M function M:__call(init) return self:new(init) end function M:new(init) return setmetatable(init or {}, self) end return M

Then content_by_lua :

local instance = require"meta".new{ a="test" } ngx.say(instance.a)

returns "nil"
But this:

local instance = require"meta":new{ a="test" }

works. Sends "test".

Yes, that was expected. The code for "." notation is a bit different:

local setmetatable = setmetatable
local M = {}
M.__index = M
function M:__call(init) 
 return self.new(init)
end
function M.new(init)
 return setmetatable(init or {}, M)
end
return M

dsgnvictor

Thanks a lot. ".new" works fine now.

I'm not sure about the "function M:__call(init)", though.

As far as I understand the purpose of this method is to enable creating instances with shorter:

local instance = M{init}

If so the "__call" should be a meta method of M, and not of the M instance {?) Sorry if I'm missing something again.

Anyway this is a code that works for me - meta.lua:

local setmetatable = setmetatable
local M = {}
M.__index = M
local mt = {}
setmetatable( M, mt )
function mt.__call(self,init) 
     return self.new(init)
end
function M.new(init)
  return setmetatable(init or {}, self)
end
return M

And content_by_lua :

local instance = require"meta"{ a="test" }
ngx.say(instance.a)

returns "test" as expected.

On Wednesday, August 10, 2016 at 7:59:29 PM UTC+2, Aapo Talvensaari wrote:

On Wednesday, 10 August 2016 20:07:20 UTC+3, Victor wrote:
Thank you Aapo.
Just one more thing. "." and ":" notations.
I created meta.lua with the sample you provided:

local setmetatable = setmetatable local M = {} M.__index = M function M:__call(init) return self:new(init) end function M:new(init) return setmetatable(init or {}, self) end return M

Then content_by_lua :

local instance = require"meta".new{ a="test" } ngx.say(instance.a)

returns "nil"
But this:

local instance = require"meta":new{ a="test" }

works. Sends "test".

Yes, that was expected. The code for "." notation is a bit different:

local setmetatable = setmetatable local M = {} M.__index = M function M:__call(init) return self.new(init) end function M.new(init) return setmetatable(init or {}, M) end return M

aapo.talvensaari

On Thursday, 11 August 2016 18:19:03 UTC+3, Victor wrote:

Thanks a lot. ".new" works fine now.
I'm not sure about the "function M:__call(init)", though

Yeah, I think it is unneccessary, and I wouldn't use it for creating new instances, but as a quick way to call something once and throw away. E.g. it could create an instance, call the instance methods, destroy the instance and return the results in a one run. But having that just for shorter "new" is, well, not something that I would do.

dsgnvictor

You're right. I was just curious how those "class" meta methods work :-)

Thanks for taking your time.

On Thursday, 11 August 2016 18:19:03 UTC+3, Victor wrote:
Thanks a lot. ".new" works fine now.
I'm not sure about the "function M:__call(init)", though

Yeah, I think it is unneccessary, and I wouldn't use it for creating new instances, but as a quick way to call something once and throw away. E.g. it could create an instance, call the instance methods, destroy the instance and return the results in a one run. But having that just for shorter "new" is, well, not something that I would do.

aapo.talvensaari

On Friday, 12 August 2016 21:31:53 UTC+3, Victor wrote:

You're right. I was just curious how those "class" meta methods work :-)

Yes, metamethods is a great concept. For new comers it might be a bit difficult to understand at first. The key thing to understanding it, is that metamethods does not have any meaning _unless_ they are used in metatables (aka setmetatable(({}, { ... table containing metatamethods ... }). And for __index metamethod you can either use a a table (aka fallback table) or a user defined function.

Great to have new people in OpenResty scene! Happy hacking! :-)

chenhong.xie

Hi, after playing around with [LuaJIT's v module](https://github.com/LuaJIT/LuaJIT/blob/master/src/jit/v.lua) without success, I found this thread to be the closest to what I need.

What I'm seeking is a code static analyzing process that tells me where I've coded *too fancily* to hinder JIT compilation, which serves something like a linter. Reading through this thread I also realized that I lack quite a bit of knowledge in JIT process. I sincerely seek your kind advice in the following questions:

1. Apart from taking flame chart in load test, can my Openresty lua code be statically analyzed of JIT compilation failures;

2. If one portion of my code doesn't JIT compile, esp. if I use some closure constructs result in FNEW or UCLO, would JIT compilation fail for all the following functions (with lua_code_cache opened);

3. Given limited resources online regarding LuaJIT details, is there any systematic documentation other than the source code itself that I can refer to, for deeper understanding of the JIT compilation process of LuaJIT

Thanks in advanced :)

On Saturday, 13 August 2016 16:08:43 UTC+8, Aapo Talvensaari wrote:

On Friday, 12 August 2016 21:31:53 UTC+3, Victor wrote:
You're right. I was just curious how those "class" meta methods work :-)

Yes, metamethods is a great concept. For new comers it might be a bit difficult to understand at first. The key thing to understanding it, is that metamethods does not have any meaning _unless_ they are used in metatables (aka setmetatable(({}, { ... table containing metatamethods ... }). And for __index metamethod you can either use a a table (aka fallback table) or a user defined function.

Great to have new people in OpenResty scene! Happy hacking! :-)