Style/RedundantFreeze stop considering ENV values as immutable

[casperisfine]

Ref: #6784

ENV["foo"] returns a new mutable string on every call.

>> ENV["PATH"].frozen?
=> true
>> ENV["PATH"].object_id
=> 260
>> ENV["PATH"].object_id
=> 280

As such it's perfectly legitimate to freeze them in a pattern such as:

PATH = ENV["PATH"].freeze

[dvandersluis]

Very interesting. Is this documented by ruby anywhere?

[casperisfine]

Is this documented by ruby anywhere?

Not as far as I know. I checked ruby spec (https://github.com/ruby/spec/tree/master/core/env) but couldn't find anything about this.

But the documentations states:

Returns the value for the environment variable name if it exists:

Which depending on how you interpret it, suggest that it goes all the way to the actual process env (i.e. getenv(3)), and doesn't keep a cache of it. So it kinda implies a new string every time.

[dvandersluis]

Thanks for digging into it. It'd probably be useful to document why ENV isn't included in the documentation for this cop IMO.

[casperisfine]

To be honest it surprised me to see it included in the first place, I'm having trouble understanding the assumption here.

[dvandersluis]

I think the assumption is that ENV works the same as a Hash, when that obviously isn’t the case. That being said, it probably is fine without explicit documentation.

[casperisfine]

I think the assumption is that ENV works the same as a Hash

More than that, it assumed all the values were already frozen.

[dvandersluis]

Well you showed they are frozen right? 😆

In any case, thanks for this change!

[casperisfine]

Well you showed they are frozen right? 😆

No they're not. They are mutable. You just get a new one on each access.

[dvandersluis]

Why is ENV["PATH"].frozen? returning true then?

[casperisfine]

Because I had a brainfart I guess -_-

[casperisfine]

Ok, that explains why I didn't understand the initial reasoning...