[LRUG] has_many :bugs, :through => :rails

[David A. Black]

Hi --

On Fri, 7 Aug 2009, Abhishek Parolkar wrote:

> Hmmm, My favorite among those , is the argument on Object#freeze , I used to
> freeze heavily at times when I wanted to protect some configuration
> parameters from being manipulated at later stage in execution. I agree that
> ruby's freeze has drawback and doesnot really protect change to the
> variable, But I do not agree with his concluding sentence , " if you design
> your software for idiots, only idiots will use it." , Even experts do make
> mistakes, and things like Object#freeze  guide all of us , to not make
> accidental mistakes by manipulating few values which should not be
> manipulated for better execution of control flow.
> 
> If I  am asked , I would say Object#freeze needs to stay and improved for
> "real freezing behavior" , and not thown out just because it doesnt do its
> freezing job well yet.
> 
> I am curious if somebody have any suggestion to over come limitation of
> Object#freeze

I don't agree with Pratik (hi Pratik!) about the first examples he
gives being weird behavior. Reassigning to a variable trumps
everything else in Ruby, so it's not surprising or weird that you can
do:

   a = "string"
   a.freeze
   a = "new object"
   a.upcase!

etc. Pratik's example uses +=:

   a = "string"
   a.freeze
   a += "blah"

but that's the same as a = a + "blah". + is not destructive, so
there's no freeze issues there, and += is unambiguously a
reassignment. (That's why there's no a++ in Ruby; Matz has stated that
he doesn't want to use traditional incrementation syntax for an
operation that is in fact an assignment.)

Similarly, I don't consider it odd that you can modify objects that an
array contains, even if you can't modify the array. Containment in an
array (or other container) has always been strictly separate from
object identity. I would not want an expression like:

   array[n]

to do anything but evaluate to an object, which may or may not be
frozen. Specifically, I wouldn't want the object to have to "know"
that the expression through which it was reached was an indexing
operation on a frozen array.

I don't think Pratik's hash example is exactly analogous to the array
example. You can't do this:

   h[key] = value

on a frozen hash, but you can do this:

   h[key] << "blah"

So hashes and arrays behave just the same with respect to freeze, I
think.

HOWEVER... I do believe there should be an unfreeze. Then again, I
don't use freeze much, so there may be cases where it's really
important that I'm not thinking of.

And let us not forget the select company of Rubyists whose last names
are, give or take capitalization, core Ruby methods:

   Jim Freeze
   Adam Keys
   Roger Pack

Those are the ones I'm aware of, anyway. (I'm still waiting for
Kernel#black.)


David

-- 
David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com
Q: What's the best way to get a really solid knowledge of Ruby?
A: Come to our Ruby training in Edison, New Jersey, September 14-17!
    Instructors: David A. Black and Erik Kastner
    More info and registration: http://rubyurl.com/vmzN