LUA question about visibility

[grump]

It's a common practice to call the class to create new instances of the class, provided "__call" metamethod is defined. It's equivalent of calling class:new but uses Lua builtin dispatch system instead of actually calling "new" manually.

Right. My confusion is not about technical details, but about the semantics in your example.

Code: Select all

local instance1 = class ( "foo" )
local instance2 = class ( "bar" )

Common sense says that class() returns a class, but you named them 'instance'.

It would make more sense if it looked like this:

Code: Select all

local Foo = class('Foo')
local Bar = class('Bar')

local instance1 = Foo()
local instance2 = Bar()

Just for sake of correctness in case OP chooses to follow your otherwise sound advice. Not trying to be needlessly pedantic.

[zorg]

there's a limit of 256 active locals per file, but the count resets for files you require().

Last I heard the limit was exactly 200 for any given scope.

It is: http://lua-users.org/lists/lua-l/2014-04/msg00385.html
At least with vanilla lua, but luajit should be the same.

[grump]

Last I heard the limit was exactly 200 for any given scope.

It is: http://lua-users.org/lists/lua-l/2014-04/msg00385.html
At least with vanilla lua, but luajit should be the same.

Time for science!

Code: Select all

local code = {}
for i = 1, 1e6 do
	code[i] = ('local x%d = %d'):format(i, i)
	assert(loadstring(table.concat(code, '\n')))
end

Code: Select all

Error: main.lua:4: [string "local x1 = 1..."]:201: main function has more than 200 local variables

[zorg]

...

You forgot the most important step though!
Don't assume the error message is actually accurate; print out the iter count where it failed!
Edit: unless that 201 is that...

[grump]

Edit: unless that 201 is that...

It is. 1 local per line, and it failed at line 201. Also, the "more than 200" message

[pgimeno]

Right, my bad.

Code: Select all

$ luajit
LuaJIT 2.0.4 -- Copyright (C) 2005-2015 Mike Pall. http://luajit.org/
JIT: ON CMOV SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse
> s = "" for i = 1, 201 do s = s .. " local x" end assert(loadstring(s))
stdin:1: [string " local x local x local x local x local x loca..."]:1: main function has more than 200 local variables
stack traceback:
	[C]: in function 'assert'
	stdin:1: in main chunk
	[C]: at 0x55d307a636c0
> s = "" for i = 1, 200 do s = s .. " local x" end assert(loadstring(s))
> s = "" for i = 1, 199 do s = s .. " local x" end
> s2 = s .. " do local x ; local x end" assert(loadstring(s2))
stdin:1: [string " local x local x local x local x local x loca..."]:1: main function has more than 200 local variables
stack traceback:
	[C]: in function 'assert'
	stdin:1: in main chunk
	[C]: at 0x55d307a636c0
> s2 = s .. " do local x end ; do local x end" assert(loadstring(s2))
> 

In the last case there are more than 200 but not all active at the same time.

[raidho36]

I just manually plopped a load of locals and indeed it's capped at 200. Note that upvalues are not locals.

Common sense says that class() returns a class, but you named them 'instance'.

Why would class ( ) return class? "__call = function ( t ) return t end"? That would be pointless. As I said, calling class object itself is equivalent to calling class:new, if you have appropriate metamethod set up. A class library object would return a blank class if you call it (or :new) but that's not what happens here.

[grump]

Why would class ( ) return class?

I'd expect class to return a(!) class, from which you subsequently create instances. There's code in my reply that illustrates my point. It's not about metamethods; it's about the difference between classes and instances/objects.

Edit: Ooh, sorry, I think I finally get you now. Your class is not a function that creates a class as one would naturally assume, it's rather an actual class that's just named "class" and it takes a string argument in its constructor? It's the only way all of this would make any sense, just very unfortunate naming, lol. This is why it's advisable to follow the usual conventions and start your class/type names with an uppercase letter, it prevents this kind of confusion from happening even when you don't know the exact definition behind an identifier.