Variable Scope guide?

General
1

Is there a guide for variable scope somewhere?

I’m curious about the difference between using

obj = {}

and

obj = class()

and what happens when you define variables within their functions. I’m hoping to find an answer to the question of how to best keep variables/properties hidden from other classes, and which approach is best for implementing a singleton class.

2

Best thing to do is look at this: http://www.lua.org/manual/5.1/ mainly parts 2.3 and 2.4.

Class is not a table, although they can be used in the same context on a very basic level, otherwise it is completely different. It took me a while to get the whole idea of classes but I think you should look this up as it is a lot for people to explain when there are so many guides/tutorials on the web. Codea uses a different class structure to some others out there as they aren’t built in to Lua the way they are in Codea, usually you would use meta tables directly off the bat but Codea does it a bit like this: http://www.rtsoft.com/forums/showthread.php?1466-A-cleaner-easier-class-idiom-in-Lua

Edit: You could use a table like this - http://lua-users.org/wiki/ObjectOrientationTutorial

3

@matkatmusic One way to answer your question is for you to read the Lua programming manual. If you do a google search, you’ll find a full version in PDF format. Or another way is to use print statements and see which variables return a nil value ( hidden) or a value you set ( in scope).

4

I posted a TouchEvent handler thread in the code sharing forum. In one of the replies, someone posted a link to an explanation of the Rollercoaster project and the use of {} vs. class(), so I was trying to expand on that. I’m considering re-writing my TouchEvent handler as a table instead of as a class, so I’m unsure about how to re-write all of the self.__ variables that exist in my class, if I rewrite it as a table.

5

@matkatmusic It’s hard to say which way is better ( table or class ). That all depends on what you’re doing with the code. Since you’re writing the code, try a smaller version both ways and see which way you like the best.

6

@matkatmusic - basically, classes are tables too, so the main difference is that a class allows you to have multiple instances of the same object (ie share the same code but have different “self” properties). If you only need one copy of an object, use a table…

You can also put table values in classes. For example, if you have a class called A, then

A.size=3 -- can be used and changed by any instance of the class, 
--ie is shared between them. Actually, it can be used by code anywhere in your project!

function A.Cube(n) return n*n*n end --can be used by any code anywhere in the project
--for example
B = A.cube(4)
7

@matkatmasic. I dont know the answer to your question.
However a class is a table with some more properties/ methods. Basically, you use class when you want to create multiple samples of your object. However, it seems that Simeon in CargoBot is using a class even for single objects that collect methods or properties. So i would follow his way.

8

@Jmv38 - sometimes it’s just easier to use classes for everything because you don’t have to remember when to use a single dot or a colon when calling functions. This can be a very confusing area for new Codea users.

9

@ignatz i think you’ve nailed it! i could not remember what was the reason i made this choice recently, but you’ve revived it!

10

but the issue is that class static variables aren’t self-contained, which you’ll have with tables. If you want them self-contained, you gotta make them exclusive to an instance via self.

obj = {}
obj.c = 0

vs

obj = class()
function obj:init()
  self.c = 0
end

I wonder if there’s a way to ‘fake’ the private/public syntax in other languages… hmm

11

@matkatmusic or do

obj = class()
function obj:init()
end
function setup()
 Obj = obj()
 Obj.c = 0
end
12

or

obj = class()
obj.a=3  --global scope, can be accessed by any code anywhere

function obj:init()
  
end
13

Hiya @matkatmusic,

You can implement a Singleton as:

local Singleton = class()

local instance = nil

SingletonInstance = {}

function SingletonInstance.instance()
    
    if(not instance) then
        instance = Singleton()
    end
    return instance
end

function Singleton:init()
    -- you can accept and set parameters here
    self.stuff = "stuff"
end

function Singleton:doStuff()
    
    -- Do something
    print(self.stuff)
end

-- Usage:
Singleton.instance():doStuff()

The local keyword makes the class private to that file, and the SingletonInstance.instance is the only way to get the one and only instance of Singleton()

But all class instance and table members are always public…

The only way to enforce real privacy would be to do:

local member1
local member2

Singleton2 = {}

function Singleton2.getMember1()
    return member1
end

function Singleton2.setMember1(m1)
    member1 = m1
end

Which creates a set of ‘file private’ attributes which can only be changed or retrieved via a set of global (‘static’) getter and setter functions…if that makes sense…

This allows you to do e.g. input checking, and stops code outside from messing with the global variables member1 and member2…

Brookesi