Strongly typed instance variables?

Here's something I thought of recently: right now in C2, like with 0.x, you can store any type in any instance variable. By type I mean boolean, number or string. So you can assign "hello" to a number instance variable.

As a result the editor can't assume that instance variables have any particular type, in case you change it at runtime. For example, Sprite: Set X to Sprite.MyStringInstanceVariable has to be accepted, in case you set that instance variable to a number at another time.

What I think would be a good idea is to strong-type instance variables. This means you can't assign a string to a number instance variable - if it is initially set to a number, it always stores a number, and can never store a string. Likewise string instance variables will always store a string, and never a number (although they can store numbers as character strings).

This slightly reduces their flexibility, but improves the editor checking - now the editor can reject setting X to Sprite.MyStringInstanceVariable, which was probably a mistake anyway.

Does anyone use the weak-typing (storing strings in number variables etc.)? I think any time you need to do that an easy workaround is just to add another instance variable. It makes sense to me. Is there general agreement?

I didn't even realize it worked that way, as I always use the appropriate variable type for what I'm doing. I vote for strong typing.

I kind of liked being able to store data where ever I liked, and using str(), or int() when ever a specific type was needed.

What about a 4th data type? One that lets you store anything.

Then again I guess you could do that with string anyways......

Meh, what ever floats your boat I guess.

One thing, hows this going to play with data storage objects?

Wont there need to be some sort of preference set?

What will happen if you try to assign a string to a number var? Will it cause an error, or variable just reset?

So in 0.x, it would change the variable type to whatever I set it to at runtime? I had no idea. :/

Newt's suggestion of a fourth type is a good one, I think. Also, please leave hash and array the way they are - having to manually set variable types for those would be a lot of extra steps.

Oh, this won't affect anything other than instance variables. I suppose if you try to set a string to a number variable, it could either ignore it completely, or do an automatic number conversion on the string.

I say yes as long as you can easily try to cast a string to a number. Would numbers have different data types like floats doubles and ints as well? What about unsigned stuff?

What would be nice would be to have type hierarchy.

Like in OOP.

And on top of that, some kind of constraints based on families. (to simulate tagging interfaces or multiple inheritance)

.... and then there's array's in instance variables. Lots of potential there.

What would be nice is something similar to Lucid's "S".

Sprite.variable(2) would give you the second value indexed in sprite's instance variable "variable".

A stack for each variable... oh heck yeah!

I vote yes. Like linkman2004 I've always used the proper type anyways. I think having it be strongly typed would help keep things ordered.

I find that 'Strongly typed' is a bit ambiguous in this case, so I'll respond using my understanding of the subject matter.

Short version: I'd be fine with it, as long as it seems uniform throughout.

I'm used to strong typing in most of the programming languages that I've used, where there is no implicit type conversion that happens at run time. If you want to perform an operation upon two different data types, you must explicitly cast one of them into the type of the other. I prefer this.

In my experience with the original Construct, it was at least somewhat weakly typed, in that one could concatenate numbers and strings implicitly. I did find it somewhat confusing that it was not uniform in that matter. For example, on a text object, if I 'set text' the result of the addition of a number and a string, it would implicitly cast the result to that of string in order to assign it to the object's Text instance variable, but the result would only be the string representation of the first variable. The second was just ignored, even if the string only contained numeric characters.

In my opinion, it should either result in error because the variables were not explicitly cast, or be more fully weakly typed and allow for implicit conversion of strings to numbers where the string consists of numeric characters.

On the other hand, I like dynamically typed variables. I like to be able to store whatever I want in a variable, whenever I want, even if I have to type check/cast in the code in some cases to make sure that it doesn't cause problems. I do occasionally use such practices.

I suppose that the cases that I can think of where this is useful can be worked around with using different variables. In fact, I'd not likely care if variables are statically typed, if the only types available are boolean, number, or string. I'd more likely use complex types in such a way.

I share newt's sentiment that there should be other data types allowed as regular variables, such as arrays (especially!) Construct was too limited with the use of arrays. They are essential to solving many problems.

However, I think that they also need to be able to be created at run time as well. I'm not sure how this would work with Construct 2. If they are allowed as instance variables, then I'd say that there needs to be a way to create arrays on-the-fly and allow arrays of arrays. Or, new instances of an object could be created in order to contain a new array, which would probably also work for me.

If arrays are separate objects as in Construct, then it would be nice if they can have more than one instance, as other objects can. Then, perhaps my sprite object (or whatever) can store an index number to the array instance that was created for it, and reference the array object by index. If I wanted each sprite to have an array associated with it, and I create sprites at run time...

Really, it's hard for me to say how I'd feel about it without knowing exactly what data types there are, and how they can be used.

If I wanted each sprite to have an array associated with it, and I create sprites at run time...

You can do this in 0.x by placing an array object in a container with a sprite.

Well, I wasn't expecting such a unanimous response, guess it was an obvious thing to do

Another question: should the 'set instance variable' action force the type?

For example if you set a number instance variable to MyText.Text, should it automatically convert it to a number as if int() or float() were around it? Otherwise, you get an error that you're setting the wrong type. Is it convenient, or error-prone since it allows things like "Set MyNumber to 'Foo' "?

I think a warning msg should pop up instead of an error msg with the options

Ok (which just proceeds with the conversion)

Cancel (so you can change it)

Or

Don't show this msg again (with the options :for this variable, for this session, for this project, ever)