Robert Klemme wrote:

> Moin moin!

Moin moin moin!

>>irb(main):034:0> File.open("C:/autoexec.bat").freeze.inspect
>>TypeError: can't modify frozen File # inspect doesn't modify
>>         from (irb):34:in `inspect'
>># This one also happens for File#path etc.
> IMHO an IO instance can't really be frozen in a meaningful way because it
> must maintain changing state (namely the stream position).  Maybe
> IO#freeze should throw an exception ("illegal operation", "cannot freeze"
> or similar).

Yup, and there definitely shouldn't be errors when trying to access the 
path of a frozen File etc. :)

(But IMHO an IO instance can also be frozen -- the internal state 
doesn't have to be frozen just because the Object is.)

>>irb(main):063:0> Dir.new(".").freeze.send(:initialize, "C:/").read
>>=> "katapult.zip" # Initialize executed despite Dir being frozen
> I would not regard this a bug since initialize is expected to change the
> instance, isn't it?

Well, [1, 2, 3].freeze.send(:initialize, 3) { rand } raises an error. :)

>>irb(main):097:0> Class.new.freeze.to_s
>>TypeError: can't modify frozen object # to_s doesn't modify
>>         from (irb):97:in `to_s'
> That's really surprising.  Maybe it's due to lazy initialization of the
> class's name.

Still, would be part of the internal state -- a frozen Object should 
still be able to change its non-exposed state IMHO. (Which means that 
freezing is an operation that is only visible to the outside, not the 
inside)

> Btw, do people frequently use #freeze?

I dunno. :)

> Kind regards
>     robert

More regards,
Florian Gross