ENIGMA Forums
Contributing to ENIGMA => Proposals => Topic started by: RetroX on January 26, 2011, 05:15:26 pm
-
This is something that I think would be particularly useful. Opinions? Not sure if they'd use the member ( . ) operator or scope resolution ( :: ) like C++. Probably could be an option.
For those that are unfamiliar, static variables are variables that are accessed by a class, or object type, rather than a specific instance.
-
Would be nice. The choice of operator depends on how close EDL is to C++- :: only exists for backward compatibility with C code that takes advantage of struct tags:
struct foo { int x; static int y; }
struct foo foo; // this is allowed
Since that's kind of obsolete and even more so in EDL, using (or at least including as an option) . is probably a good idea.
-
I'm also in favor of . especially for consistency. It's also the way Java does it.
-
I like the scope resolution because it treats classes like namespaces. I found how Java did it as being weird. :V
-
Java and C# use . for namespaces, classes and objects. It's more consistent and simpler. The only reason for a different operator is to support struct tags, which are only needed to allow variables named after types, which nobody does anymore even though it's possible. You can treat classes as namespaces without ::.
-
As it stands, ENIGMA uses . for all other access. A single dot will represent the correct choice of GM access (integer.variable), instance access (inst.member), or pointer access ((&inst)->member). I was considering having it resolve scopes as well, but it may require a special flag on results from the type resolver or before the call to it, depending on how I have it structured (An actual 'int' keyword should be distinguishable from an int variable).
-
Well, I suppose that it will be fine. I still find it weird to have one operator for everything, but as it stands, I think that it will be fine.
-
Frankly, I kind of like it better as ::, too. I'll see about supporting all three ( . -> and :: ) for their C++ purposes.