Constants and Arrays: What is wrong with this picture?

[Glitchfinder]

I've been pondering this question for a while, and finally decided to ask. If a constant is supposed to be uneditable and invariable, why can a contant array be edited? Specifically, if you have Constant = [], why can you then change the values within the brackets? I mean, that breaks the whole definition of a constant, right? Anyway, I'd love to see what other people think on this matter, or to find out that a constant is actually all caps, or someting like that. Anyway, thanks for the help!

 

[SephirothSpawn]

Constant can be changed, but shouldn't, no matter what. There is a reason for this, only because some constant interact and need to able to be changed, like in the editor. Unfortunately, making them editable in one section of a script means they can be edited from an event too. Really no way around this.

Just don't change your constants unless you are in the script editor and you know what you are doing.

 

[Glitchfinder]

Well, I haven't really looked at the constants in the default program. From what I remember, the only constant I found was the CENTER_X and CENTER_Y ones, which I have played around with. On the other hand, if you look at the timer script I made (here), you'll find that I actully used this to my advantage. (For some reason, I just couldn't get it to work without using constants, so I went with the flow. I believe you corrected another script where I did the same kind of thing, and showed me how to make it use (non-constant) hashes instead. (I believe it was that random-levelup stats one) Anyway, I just thought it was odd that the program allows you to modify constats if they are arrays. (On the other hand, from my testing, it only allows you to modify what is within the array, but not the fact that it is an array. It is almost like the constant sees the array as the value, but the array just points toi non-constant values. (I mean, it sees the value as a pointer, and not as the array full of values) If the array class works differently from the other values, be them integers, floats, or strings, that might explain it. (As in, if the array is just a complex wrapper class for a bunch of the other variable classes, and just points to the values that are stored elsewhere)

 

[ERZENGEL]

I believe that constants can be changed because class names are constants in Ruby and when they can not be changed you can't add methods, etc. to the class.

But there is a way to make constants unchangeable:

A = Array.new()
A.freeze()     # !!!
p A[1] = 2     # error
p A = 2        # error
p A.frozen?()  # => true

And this works not only with constants... you can freeze instance variables, classes and instances of them, etc.
The Graphics module has a class method called "freeze". This is not the same! The frozen status of objects can not be deactivated by default. Evil Ruby has a way to unfreeze objects. Or you duplicate objects (cloning does not unfreeze the object):

a = A.dup()
p a.frozen?()  # => false
a = 2          # no error

 

[Zeriab]

Constants in ruby are actually not constants.
Constants are instead treated pretty similar to global variables. (There are certain scope differences)
You are perfectly free to do something like this: (And vice versa)

$game_system = Game_System

The semantics allow this structure. You can use the same method for $game_system and Game_System.
Conceptually... Well I think you can guess what I think about it.
I believe like ERZENGEL that you can change constants to allow extensions to classes. The majority of scripts on this forum would not work were you not allowed to do so.

I would suggest that you generally treat constants like they are actual constants. (With the exception of extending/changing classes)

@ERZENGEL:
You are not right about how the .freeze method works. It freezes the object itself, not the reference to it which in your case is a constant. You do get an error with the A[1] = 2 but not with A = 2. Look at this example:

A = Array.new()
A.freeze()     # !!!
p A.frozen?()  # => true
p A = 2        # 2
p A.frozen?()  # => false

Note also that freezing objects only prevents assigning instance/class variables to new objects.
You can for example try using this:

$game_switches.freeze

What do you believe happens when you change a switch?

*hugs*
- Zeriab

 

[vgvgf]

Actually, if my memory doens't fail, in pure Ruby, with the original Ruby library(Not RGSS) constants can't be edited, doing so throws an error. So the shitty and edited RGSS ruby, which doesn't have functions like require .so files(Blame you Enterbrain for that!), has been edited for allowing constants being changed without problem. However I doesn't see much difference between(including in original ruby) using a global/class variable and a constant, you can make the same things with both of them without problems(suposing that you needn't edit the vairables).

 

[e]

No, in pure Ruby constants can still be altered.

Basically, in Ruby:

• The constants internal representation may be modified at any time during execution.
• Constants defined within a class or module may be accessed anywhere within the class or module.
• Outside the class or module, they may be accessed using the scope operator, :: prefixed by an expression that returns the appropriate class or module.
• Constants defined outside any class or module may be accessed as it is or by using the scope operator with no prefix.
• Constants may not be defined in methods.
• Constants may be added to existing classes and modules from the outside by using the class or module name and the scope operator before the constant name.