Forum: Ruby-core [Ruby 1.8 - Bug #4578][Open] Fixnum.freeze not frozen?

C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 unknown (Guest)
on 2011-04-15 01:22
(Received via mailing list)
Issue #4578 has been reported by Russell Bevers.

----------------------------------------
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.
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 unknown (Guest)
on 2011-04-15 02:34
(Received via mailing list)
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.
B397b498cc02503a2d86c86176f7fd3e?d=identicon&s=25 Magnus Holm (judofyr)
on 2011-04-15 07:32
(Received via mailing list)
Isn't technically all Fixnums "frozen" (because you can't modify the
state)?

// Magnus Holm
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2011-04-15 07:42
(Received via mailing list)
Hi,

In message "Re: [ruby-core:35767] Re: [Ruby 1.8 - Bug #4578]
Fixnum.freeze not frozen?"
    on Fri, 15 Apr 2011 14:31:53 +0900, Magnus Holm <judofyr@gmail.com>
writes:

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

Not really, since fixnums could have instance variables.

Thus, theoretically, there's room for freezing fixnums.  I don't think
it's worth the cost though.

              matz.
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2011-04-20 00:00
(Received via mailing list)
On Fri, Apr 15, 2011 at 12:37 AM, Yukihiro Matsumoto
<matz@ruby-lang.org> wrote:
> it's worth the cost though.
I guess you mean the cost in MRI. In JRuby, Fixnums *could* be frozen
(we don't enable it to match MRI), but the same value is not
guaranteed to be the same object throughout the system. Tradeoffs!

- Charlie
06f01d76b4705d0dd87a4a4cd63cb3a9?d=identicon&s=25 Russell Bevers (Guest)
on 2011-04-26 18:09
(Received via mailing list)
Issue #4578 has been updated by Russell Bevers.


BTW, freeze & frozen? work fine on Fixnums in 1.9.x on my platform.  I
agree that it seems unnecessary to correct in 1.8.x.  I can move to 1.9.
----------------------------------------
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: -


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.
This topic is locked and can not be replied to.