[ruby-core:35767] Re: [Ruby 1.8 - Bug #4578] Fixnum.freeze not frozen?

Isn't technically all Fixnums "frozen" (because you can't modify the state)?

// Magnus Holm


On Fri, Apr 15, 2011 at 02:34, <[e-mail]> wrote:

>
> Issue #4578 has been updated by Shyouhei Urabe.
>
>
> You agree integers are immutable.  Immutable objects have no states by
> definition, OK?
>
> The frozenness is a state.  You should not care about.
> ----------------------------------------
> Bug #4578: Fixnum.freeze not frozen?
> http://redmine.ruby-lang.org/issues/4578
>
> Author: Russell Bevers
> Status: Open
> Priority: Normal
> Assignee:
> Category:
> Target version:
> ruby -v: ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-darwin10.7.0]
>
>
> Using ruby 1.8.7 p334
>
> a = 5; a.freeze
>
> Expect:  true == a.frozen?
> Result:  false == a.frozen?
>
> I realize Fixnum is already immutable, however consider the following code:
>
> class Demanding
>    attr_reader :important
>
>    def initialize(important)
>        @important = important
>        @important.freeze
>    end
> end
>
> Demanding wants to be able to rely on identifier not changing over its
> lifespan.  I could make it demanding with some other mechanism such as:
>  * Force important to be a particular type
>  * Force important to respond_to? particular messages during initialization
>
> These are all slippery and don't address the concern of mutability of
> important objects.  Freeze seemed like the obvious solution, but it's
> probably best for me to just take a deep copy of important for Demanding's
> own use.
>
> In the meantime, I thought I should share that freeze is not working for
> all objects in Ruby 1.8.7 p334.
>
>
> --
> http://redmine.ruby-lang.org
>
>