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

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

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

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

[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?

[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