Sneak peek: r36 Local Variables

Hi all,

Just thought you might like to see how the next build is shaping up. I've been working on global variables, as per request in the last poll, but also adding in a 'local variables' feature as I go.

If you ever needed a temporary number to store a value just for a couple of events, local variables are perfect. Previously you'd have to add a global variable or stow it away in an instance variable. The problem is those are visible to the rest of the project. Lots of these temporary variables end up 'junking up' the project with random bits of data.

Local variables are a new type of event block. They look a bit like comments, but declare a temporary variable that is only usable in its "scope". At the top level, they're global variables, but in a subevent, they become local and are limited to use within that one subevent.

For example, to calculate the average position of a bunch of objects, you need a temporary place to store the sum of X and Y values. With local variables it looks like this:

<img src="http://www.scirra.com/labs/localvars.png">

The variables Xsum and Ysum don't appear anywhere outside that subevent, so they don't mess up the project.

This is a totally new feature for C2! I'm not aware of anywhere a feature like this has been done before. You'll be able to play with it in the next build! If you have any ideas that would make this extra-awesome, let me know

Cool, this feature is pretty useful. Can you, for example, put the declaration block as subevent of an event, and then just set the value in the declaration block without using any actions?

Like:

[a collides with b]

subevent: Local number aPosition = a.x

?

maybe it wouldn't even have to be a subevent, just a same level linked event.

I'm just a bit concerned that having them only apply to one subevent makes them a bit limiting. Sometimes an algorithm takes up a few events.

EDIT: ok, I think what you meant was nesting level. I was under the impression that you can only use them in that one event they're linked to.

Initialising a local variable with an expression like Sprite.X isn't going to be supported immediately - it's a little complicated - but it will come in a later build. For the first release if you need an expression all you need to do is follow with a 'set variable' action.

They're not limited to one event: they can be accessed in all its "sibling" subevents and subevents to all those events. It's like scope in programming languages: you can use local variables everywhere inside the curly braces they're defined in, but not in code outside of that. This gives another advantage: you can re-use the names in different scopes, such as having 'sum' in one subevent in one place, and another 'sum' in another subevent somewhere else.

Do the variables and their values only last one tick, or do they remain for multiple ticks? I think they'd be far more useful if they would last for multiple ticks.

I was considering having them reset to their initial value every time the event ran. If they persist their value they're exactly like global variables, but only accessible within their scope. Does that sound like a better idea?

I'm not sure: if they persist, in the example in the original post, the second time you click the Xsum and Ysum values increment from their old sum values, which might be unexpected.

Hmm... perhaps a 'retain value/reset value" parameter?

I'm not sure either. One benefit of doing it this way over normal globals though is they can be created dynamically at runtime. I personally would like the option for them to be able to retain their values, but if not, I can continue using a hash table for that instead. Either way, looks handy!

One other thought, I assume the syntax checker will properly know if a local variable is currently usable/within its scope or not?

Yes, the syntax checker knows which variables are available in the current scope.

I'm siding with not persisting values for local variables. If you want a persistently stored value I don't see why you wouldn't use a global variable instead.

Local variables are intended for small clusters of events where you need somewhere to temporarily dump a value, but you don't want to be forced in to using a global or instance variable. I think for this purpose, non-persistent local variables are fine.

In programming languages, local variables by default are not persistent either - they're the same kind of temporary holding space.

Does that sound fair? I can do the initial release with non-persistent local variables, and everyone can have a play with it and see how it works out. If it turns out it would be really useful to persist them I can always change it later.

I agree with Ashley I would make them work like they do in c++. Im not sure its the most intuitive for new people but it is something that has to be learned anyways and when you move on to another language that idea of local variables will persist and in the end teaches people proper programming practices.

How about both, a local value, and a non declared variable?

Also arrays.

Arrays are kind of another thing to tackle entirely - if we're going to do arrays, we might as well go all-out and implement proper data structures, basically re-do the entire 'S' plugin except with a visual array editor and make the entire thing much easier to work with. But that's for another topic.

Anyway, this is a fantastic idea, and I approve. I don't think there's any point in making them persist.

Yeah, I guess it sounds fine since a hash table is so close to the same thing if I want persistent variables. Also, good point Aeal.

I like it. I remember times when I'd use these in C.x. Do you know, when David is going to finish the graphic editor? That's probably last thing, that's stopping me from using C2 more.

I think that would be more intuitive if the local variable declarations were actions and not something similar to events. It is probably harder for non coders to understand as it's not so consistent with the condition>>action system. In fact I think it would be even more intuitive if local variables don't need to be declared at all. They should be automatically declared when you add, set or substract a local variable. This would probably make things simpler.

This is pretty cool, very nice feature. Don't have to create pointless clutter sprites to store variables anymore!

Do you know, when David is going to finish the graphic editor? That's probably last thing, that's stopping me from using C2 more.

Hopefully not more than a couple of months - we're not fulltime just yet. I'm well aware this is the biggest shortcoming in C2 at the moment, we're going to sort it out ASAP.