|
|
Josh @ Dreamland
|
|
Reply #17 Posted on: March 12, 2010, 07:30:42 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Grundoko-- This is only while declaring them, which is entirely optional. GM offers no such functionality. Here, "local" means "object-local." GM doesn't offer a method of declaring things, it leaves them all var. ENIGMA does this by default; declaring them is an extension of GML. "local var" does essentially nothing.
"The whole `var` class thing doesn't work the same way as GM's `var` keyword." Care to back this up with examples?
|
|
« Last Edit: March 12, 2010, 07:40:02 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #20 Posted on: March 12, 2010, 09:46:43 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Grundoko:
No, "local" tells the compiler that the following declaration belongs to the current instance rather than the current script. In GM, "var" declares variables in the current script, and these variables are freed after the script is called. There is no way to declare an instance-local variable (such as x or y) in GM, because there is no need to; GM's only type is var. In ENIGMA, however, we have more than one type. So.
In GM, you'd say
var i; for (i = 0; i < 10; i += 1) ... in ENIGMA, you'd say for (var i = 0; i < 10; i += 1) ... OR you can say for (int i = 0; i < 10; i += 1) ... That's an easy way to speed up your code, since int is more than 10x faster than var in ENIGMA alone (there's really no point comparing it to GM's var's speed).
However, as I said, GM doesn't offer a way to declare object-local variables like x and y, because its only type is var. To bring other types into the mix, R3 used a keyword "localv."
Saying "localv int a;" made sure that "a" was the same variable in all codes called from that object, and ensured that it was an int.
Now, I can leave it like it is, or I can change "localv" to "local," or I can remove "local" entirely and use "var int" when declaring SCRIPT-local variables, making our for loop from before look like this:
for (var int i = 0; i < 10; i += 1) ...
SO. If we use "local" this way, here's the layout: local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y". int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML. a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
|
|
« Last Edit: March 12, 2010, 09:49:55 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
The 11th plague of Egypt
|
|
Reply #21 Posted on: March 13, 2010, 12:22:42 am |
|
|
Joined: Dec 2009
Posts: 274
|
SO. If we use "local" this way, here's the layout: local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y". int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML. a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
So writing a=0 means writing var a=0 in the sense of GM var? But then our object create events are still screwed. Or you mean something like local var a? And var int a=0 or local int a=0 would be 2 other completely different things. Then we have 3 ways of declaring a variable: 1 for retro-compatibility and 2 to define?
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #22 Posted on: March 13, 2010, 12:25:48 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything. I meant object-local that time, yes. Fix'd: a = 0; //"a" is assumed to be an OBJECT-local variable, accessible from all events, and will be given type "var" if no one else says anything. And yes, I suppose, but two overlap. 1) Not declaring variable: Both GM and ENIGMA assume object-local var 2) var a: Both assume script-local var int a: ENIGMA assumes script-local int 3) local int a: ENIGMA creates object-local int
|
|
« Last Edit: March 13, 2010, 12:33:13 am by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Game_boy
|
|
Reply #23 Posted on: March 13, 2010, 06:16:00 am |
|
|
Joined: Apr 2008
Posts: 228
|
I'd prefer "int a" to mean object-local int, and "local int a" to mean script-local. So none of the options on the poll, but if it was there it would be "int, local int". But to make it compatible with GM, "var int" should be a script-local var type. Since "a" is declaring an object-local variable, and by saying "int a" I only want to change its type to integer, not to make it script-local as well.
So:
a (object-local var type) int a (object-local int type) local int a (script-local int type) var a (script-local var type)
Result: compatible with GM, but declaring a type doesn't make it script-local automatically, which I would call unexpected behaviour.
|
|
« Last Edit: March 13, 2010, 06:20:37 am by Game_boy »
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #24 Posted on: March 13, 2010, 10:09:12 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Game_boy-- I wasn't sure what people expected. When I say "int x;" in any language of that syntax, I expect "x" to last only as long as the script does. I was hoping to glean an accurate representation of the GM mindset; I just assumed that like "var a;", users would expect "int a;" to make a script-local, and would never even consider modifying object-locals like "x" and "y". But then again, I can see it becoming confusing when they want to identify that a regular local they are using as that particular type.
The thing is, when they discover that ENIGMA has types, will they treat them exactly like var, or will they assume they can just la-dee-dah define object-locals with it?
How many will actually go to the manual to see how they work? Assuming I ever even write a manual. I'm lazy with easy tasks that take time. If they all went to the manual, I think "local int" would be perfect for object-locals. Since that probably won't happen, I need to know the mindset and minimize damage when they misuse it.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Micah
|
|
Reply #25 Posted on: March 13, 2010, 12:26:43 pm |
|
|
Joined: May 2008
Posts: 128
|
"The whole `var` class thing doesn't work the same way as GM's `var` keyword." Care to back this up with examples? The `var` keyword in GM is not analogous to a type name in C++. In GM, the scope of a variable is decided by the keyword, or lack thereof, that you use. Nothing means object scope, `var` means script-/event-local scope. `globalvar` means global scope. In C++, the scope of a variable is decided by where it is declared. In a class definition is object scope, inside function or control-flow {}s is block-local scope, and outside functions is global scope. The keyword you use defines the type.
|
|
|
Logged
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #27 Posted on: March 13, 2010, 04:35:54 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"In GM, the scope of a variable is decided by the keyword... In C++, the scope of a variable is decided by where it is declared" Are you suggesting that in GM, where it is declared has nothing to do with it? Certainly you aren't, since you said "`var` means script-/event-local scope" and didn't seem to think that was decided at random... Let's look at JavaScript. function script0() { var a; // "a" is local to script0() b = 0; // b is local to the current context, such as a web page } This is probably a better example of var scoping, with var working just like a class in C++, and behavior of undeclared variables mirroring that of GM. JavaScript, of course, is classless, so you won't see that done with any type other than var. Does that make var JS and GML's only type, or just another keyword? The behavior is the same; that makes it a matter of opinion. Game_boy: I understand. In fact, that's a really good point. Give it a vote.
|
|
« Last Edit: March 13, 2010, 06:22:52 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #29 Posted on: March 13, 2010, 07:07:32 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
The changes that I've made polls for so far (or may yet make polls for) don't affect GM interoperability. However, I intend for ENIGMA-GM communication to be one-way. I'm kind of glad that most users are going with my take on this issue, because part of the philosophy behind these changes is for ENIGMA to be able to see off its users with a smile instead of a sore ass. Game_boy admits to not thinking of "var" being a type; he never expected to see anything other than var in GM, I guess. I was always on the lookout for something other than "var," I didn't think a keyword very useful that just says something is local. And when I heard the word "declaration" attached to it, and started catching wind of more powerful languages than GM, I just kind of assumed (correctly) that they would parallel this structure with less ambiguous types. Game_boy: when you think about "var" as a class rather than simply a keyword, does it seem more logical? Or less? Right now, GM is breeding a wave of people who don't understand that == is an operator. I can't allow ENIGMA to be like that. This is what will happen as a result: The ENIGMA default configuration when creating a new file is currently as follows: Strings: | GM Style ("\") | Comparison: | = or == | Operator ++: | Enabled | struct {}: | Treat } as }; |
When importing a GM file, a separate set of default settings will be used, currently differing by one setting: Strings: | GM Style ("\") | Comparison: | = or == | Operator ++: | Disabled | struct {}: | Treat } as }; (inapplicable) |
The settings for either can be modified at any time, and will be saved with the EGM file. Now, with that in mind, what I meant by "see[ing] off its users with a smile" is this: As users become used to ENIGMA, they'll start looking through its new features. The most obvious features will likely be the first they use, take the for loop example from before. What they once knew in GML will be made easier (and much, much faster) in EDL: /* Old: */ var i; for (i=0; i<10; i+=1) draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);
/* New: */ for (int i=0; i<10; i+=1) draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1); Now users can legitimately declare their variables inside a for loop (with better scoping) and can take advantage of a type literally hundreds of times faster than what they are used to. This will be revolutionary for all of ten uses, and they'll be accustomed to it like everyone else. It'll once more be no big deal. Then they'll find other nice things: /* Before: */ var a; a = ds_list_create();
/* After: */ list a; Or object-local: /* Before: */ a = ds_list_create();
/* After: */ local list a; And then, as they get used to that: local list<int> a; Slowly, their default options list will get closer to mine: Strings: | C++ Style ("\\") | Comparison: | == | Operator ++: | Enabled | struct {}: | ISO |
At that point, ENIGMA will, like GM, cease being a challenge. Maybe cease to offer what they feel they need. Also like in GM, maybe they'll start developing for the project; DLLs or, since this is compiled, just a new library. And if ENIGMA still isn't enough for them anymore, they can move on, knowing a decent amount of a pretty good language.
|
|
« Last Edit: March 13, 2010, 07:12:40 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|