What's the difference between stuff-at-the-start and the `setup` routine?

Questions
1

In various examples I’ve seen code with some stuff at the start as “bare code” and then an explicit setup routine. I don’t see the difference between these two parts of the code. What should do inside the setup routine and what should go outside it?

2

Because the “bare code” is run before all files (tabs) are evaluated. You can run into a situation where code in the global scope may try to call a function or create a class that doesn’t exist yet.

If you create all your globals in setup() instead, all files are guaranteed to have been processed by the Lua interpreter.

(The examples violate this at times, I’m thinking of correcting them)

3

I see. Thanks.

So it might be useful for a class file to have stuff as “bare code” for defining some default stuff that the main program might want to override but doesn’t have to. Then anything in the setup could override the original setting in the class file, but it wouldn’t have to say anything if the default was fine.

4

I’m not sure I understand what you mean. Do you have an example? You can override things in global scope, but you can also setup global values from anywhere, as Lua is global-by-default.

5

Yes, I have an example.

I have a class which represents a pendulum. It contains within it the code for working out how it moves (under various assumptions on the physical model). This works by a step-by-step solution of the differential equation. So it needs a step size. This has to be set. It should be a global variable since it doesn’t make much sense to vary it on a per-pendulum basis. So I can define it in setup. But if I decide on a sensible value that works in the majority of cases, it would be useful to define that in the class file so I don’t have to define it in every program that uses this class. So the class should define a default which the main file can override. The simplest way to do this is to ensure that the default is defined first and the override second. So putting step_size = 0.05 in the bare code in the class file and step_size = 0.1 in the setup routine in the main file achieves this end - assuming that I’ve understood correctly what you’ve told me.

6

Why would you not put it in the class init()? That’s run automatically when you instantiate the class. It would also keep it from being a global, and let you pick it on a per-object basis (which doesn’t make as much sense for this, but might for other default settings).

I try very hard to avoid polluting the global namespace unless I absolutely have to - it’s bitten me too many times…

7

My assumption is that the class init is run once for each object. This particular variable should be a once-for-all-objects variable. Maybe I should read up on lua namespacing so that I can define per-class variables and then each object should have a method to change that variable in such a way that it changes it for all objects.

In this case, though, it does make sense as a truly global variable as it is the clock tick against which all things measure their time. I agree that as a general rule, things should not pollute the global namespace, but from time to time then rules can be broken.

8

Hmm in that case I’d say it’s mostly a stylistic choice, regarding how you want to handle it. I would probably do it like this:

MyClass = class()
MyClass.STEP_SIZE = 0.01

function MyClass:init(a, b, c)
    self.timeElapsed = 0
    -- ...
end

function MyClass:update()
    self.timeElapsed = self.timeElapsed + MyClass.STEP_SIZE
end
9

That looks good. I think I’ll steal … I mean, use … that.

10

Note also that you can define class-level variables but access them within objects through the self reference.

For instance:

MyClass = class()
MyClass.stepSize = 0.01

function MyClass:init(a, b, c)
    self.timeElapsed = 0
    -- ...
end

function MyClass:update()
    self.timeElapsed = self.timeElapsed + self.stepSize
end

I usually do this so that I can easily decide later to set it per instance. You can even set it on some instances and the rest will fall back to the class-level definition.

I prefer to not have a different naming convention for class and instance variables for this reason.

11

Nat’s solution is better than mine. You should use that. Also caps and underscores are harder to type on iPad.

12

Also caps and underscores are harder to type on iPad.

Ah, but I’m doing my main editing with Emacs …