Private variables

[cbk1994]

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

PHP Code:

function setVars() {
  private this.foo = "bar";
  protected this.var = "str";
} 


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

[cbk1994]

bump

[Crow]

I agree, would be a nice addition.

[Chompy]

I support this!

[Inverness]

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

[Codein]

Good idea, I totally support.

Originally Posted by Inverness

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.

Why?

[Chompy]

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

[Codein]

Originally Posted by Chompy

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

I agree

[Loriel]

Originally Posted by cbk1994

Other scripts would have absolutely no indication that "this.foo" even existed.

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

[Inverness]

Originally Posted by Codein

Why?

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.

Originally Posted by Chompy

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

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.

[Codein]

Originally Posted by Inverness

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.

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:

PHP Code:

private this.pr_var = "redfish"; 


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.

[Loriel]

Originally Posted by Inverness

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.

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

const is not part of GScript itself, they are resolved by the compiler, similar to a macro in C.

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

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

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

[Inverness]

Originally Posted by Codein

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:

PHP Code:

private this.pr_var = "redfish"; 


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 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.

Originally Posted by Loriel

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

Well if every member variable is private you don't need a private keyword then.

Originally Posted by Loriel

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

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.

[Codein]

Originally Posted by Inverness

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.

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.

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.

[Inverness]

Originally Posted by Codein

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.

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.

Originally Posted by Codein

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.

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.

Originally Posted by Codein

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.

With Graal scripters it's much better to force them to do it a certain way, they just don't follow convention.

[Codein]

Originally Posted by Inverness

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.

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

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?

Originally Posted by Inverness

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.

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?

Originally Posted by Inverness

With Graal scripters it's much better to force them to do it a certain way, they just don't follow convention.

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.

[Inverness]

Originally Posted by Codein

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.

PHP is not used the way GScript is, Graal is a constantly changing environment and GScript is equipped to deal with it dynamically.

Originally Posted by Codein

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

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.

Originally Posted by Codein

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

I'd be more interested if Graal was actually updated with the variety of features scripters have been suggesting for months and years.

Originally Posted by Codein

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?

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.

Originally Posted by Codein

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.

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.

[Codein]

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

[Twinny]

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

[Inverness]

Originally Posted by Twinny

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.

[cbk1994]

bump

[cbk1994]

bump