> |>                                In addition, Ruby interpreter depends
> |> on the fact that frozen objects, especially strings, are never be
> |> unfrozen.
> |
> | This is because, rb_str_new4() and rb_str_dup_frozen() don't create a new
> | object when the string is frozen ? Is this the only reason ?
> 
> Uh, maybe.  Some part of string copy-on-write system depends on the
> fact that frozen strings would never be modified.  I'm not sure proper
> copying on those two functions make unfreeze possible.  When I confirm
> it, I would happily add Object#unfreeze to the future Ruby.

This came up on -list, too.  and, IIRC, you said it'd be possible (or
easier?) to add #unfreeze if we'd have two freeze, one with
unfreezable capability and the other with current non-unfreezable
freeze.

I couldn't even find nice method name for those two, so I didn't
follow up that post. maybe native english speakers can came up with
nice name.

btw, this came up when we talked about initial state for Hash's
default instance variable. (currently it's not freezed 'cause there is
no way to thaw/unfreeze.  but freezing it might help preventing
unexpected change.

regards,
--
        yashi