Private variables
 

Support for protected and private variables would be very nice, even if only added serverside.

Other scripts could access "this.var", but not edit it. Other scripts would have absolutely no indication that "this.foo" even existed.

I'm pretty sure this has been requested before, but it still hasn't been added :(

bump

I agree, would be a nice addition.

I support this!

I think private variables would be better implemented as some sort of prefix like __ rather than as a keyword. this.pr_blah would be private or so.

Edit: I like this.__blah__ better :)

Good idea, I totally support.

Why?

I think they would fit good as keywords, such as const :p

I agree

What would happen if some other script tried to set it?

Graal is highly dynamic language, I don't think it's a good idea to have private variables unless there is easy to tell the access level of any variable.
const is not part of GScript itself, they are resolved by the compiler, similar to a macro in C.

Making changes to a language syntax is something that requires alot of thought, and I'm annoyed with the lack of it right now.

Hrm, I can see what you mean. However, I don't agree that the 'pr_' prefix is the best way to DECLARE a private variable.

Maybe something like this:

Where the keyword actually declares the variable as private, and the name indicates that it is a private variable, as some sort of convention maybe.

I think indicating what's private and what's not should be completely down to the programmer.

I do not see what being dynamic has to do with anything. In Ruby, which is dynamic as ****, every member variable is private.

By that logic, C has no language features since they are all resolved by the compiler to assembly.

Just give us Scheme macros so we do not have to bug Stefan to change the syntax for us. :\

I am 100 percent against a private keyword. Graal is too dynamic to have variable behavior changed by keywords.

I think this.__var (or this.__var__) is a much better way of indicating a private variable, because you can simply look at it and know that it's private without having to use a function to check the access level.

A great many scripters on Graal don't understand the importance of convention in a scripting language and Stefan makes no effort to try to enforce one. So even if you propose a convention it will most likely not be upheld and everyone will just indicate private variables however they please. My proposition forces scripters to name the variable a specific way if they want the functionality. You're defeating yourself with your own argument's complexity, simple is better.

Edit: Also, isn't it rather redundant to have both the keyword and the convention? If you're wanting everyone to use pr_ to indicate private variables, why not simply make that the way to declare them? That way you don't need to make a more complicated change to GScript by introducing access level keywords.
Well if every member variable is private you don't need a private keyword then.
:rolleyes: I'm saying that const is a compiler feature, not really a feature of GScript. With the proposed access level keyword, that would not be the case. So you can't say private would fit good with keywords such as const, because const isn't part of GScript, and an access level constraint certainly is.

Edit2: I just noticed I reached 3,000 posts, yay me.

Yeah, I can see exactly what you mean. However, I still think a keyword would still be best. I mean, I have, for some time, wanted some kind of support for classes, in a traditional sense and keywords for declaring class members would be necessary in my opinion.

Also, I don't see you preaching conventions, being in a position of influence within the scripting community. If you shown the importance of them, like many other of the Scripting Elite on here, there should be an improvement in that field.

Regarding your edit, the convention is optional, as with any convention. It's just recommended. There's something about using what LOOKS like a convention as an actual declaration gets to me, for some reason.

However, I'd just like to see private variables. If Stefan agrees with you, I'm not really bothered, as such. It still does what I want.

Python is a very popular language and it implements classes just fine without variable access keywords. Something like private variables are implemented using name mangling with variables prefixed with '__', __e becomes __Pancake_e where Pancake is the name of the class, avoiding collision by inheritance. There isn't an absolute way to prevent variable access and I don't think one is necessary in Python or Graal.
I'm not a miracle worker. I also don't care too much about what other people do as long as I don't have to look at their scripting. And I think you overestimate my influence.
With Graal scripters it's much better to force them to do it a certain way, they just don't follow convention.

Haha, I knew Python was going to come up one time or another in this topic :p

The thing is in other scripting languages, such as PHP, keywords are used and work fine and I actually PREFER them. It makes it much much clearer to see how certain variables are declared and how they should be used, looking through a script. That, COUPLED with the convention, it's a winner, in my opinion.

Can you explain how Graal is TOO dynamic for keywords? How have you come to that conclusion?

Aye, you're not a miracle worker. It also disppoints me to hear your lack of consideration and interest in up and coming scripters.

Overestimating your influence? You've had influence over MANY a scripter. Maybe you're blind to this, because of your lack of consideration for new scripting talent, maybe?

I don't think taking a forced approach is the best way. Many scripters, after a while of scripting, explore other languages. They need to learn that, although optional, convention is still important.

PHP is not used the way GScript is, Graal is a constantly changing environment and GScript is equipped to deal with it dynamically.
Objects and their variables are often serialized and deserialized as "varname=value". This format is not equipped for specifying the access level of variables. If the access level was dependent on the variable name, no changes would be required for any of this.
I'd be more interested if Graal was actually updated with the variety of features scripters have been suggesting for months and years.
Ever since I moved on into the world of C/C++, Python, and Lua I've grown to dislike GScript because of its inconsistency among other things. It doesn't inspire me to help with new scripting talent or such things.
Convention can be taught with other means rather than with something so important as private variables.


Let's break it down:

To implement my suggestion, Stefan would need to implement a fix to the variable set and get functions in Graal so that if you're getting a variable that starts with __ from something other then yourself then you get denied.

To implement your suggestion, Stefan would need to modify the compiler to recognize variable access keywords, add functions for getting the access level from variables. Since I doubt changes would be done to save file format, you would only be able to load private variables into an object if the variable already exists and has been declared private, or you could possibly set a private prefix for the load function, which ends up doing what my suggestion would do automatically. And depending on how it's done, all objects would have an increased (minor) memory footprint so variables can store their access level. If you want to avoid that then you'd need an array or hash table of private variable names which would just make variable access slower.

Taking into account the way variables are serialised, I think your way would be the better way to implement, yeah.

From my thread on this, http://forums.graalonline.com/forums...ad.php?t=71199

Stefan originally suggested the possibility of thisr. or this.protected.whatevs

I think it is better to have the indicator in the variable name because of the reasons I mentioned above, imho. thisr. isn't really part of the variable name.

bump

bump