def submit_button(caption, type=:input)
# Code for :input, :button, :image, :a_with_onclick or whatever
end


…or there’s the slightly more familiar approach of the options hash:


def add_column(name, type, default_value=nil, options={})
# code which checks for options[:not_null], options[:key], options[:constraint],
# options[:comment] et cetera.
end


What’s GC, really?

Say, you create a hash as in Glu.ttono.us article listed above, {“abubu” => “ububa”}, and create another hash, oddly enough, also {“abubu” => “ububa”}. Well, four strings created, and if you delete the first hash, GC will kill two strings for ya.

If using symbols, you don’t have those extra strings to delete anyway.

And no matter how long your program runs, or whatever fancy loops and hoops it does, if you’re not dynamically creating symbols via #to_sym, only those specific, unique symbols you’ve explicitly named in your code will live. 1Mb memory leak is around 260k such symbols can you even imagine that many symbol names?

As Khaled said, you’re ok unless you start dynamically creating thousands of symbols somewhere.

So use symbols as much as you can, and avoid using stings as much as you can, but take extra care of defining thousands of symbols, cause as mentioned: symbols don’t get deleted till program exits, and thus they stick in memory.

The GC would not have to clean this :Khaled alhabache symbol, cause symbols don’t get deleted till program exits.

How is that considered considered a more efficient use of memory? The same result as interpreted from others has been:

Let’s start off with memory. Every symbol is a memory leak. I don’t know who said that first, but it’s a great way to think about symbols. Every symbol lives forever

from Josh Susser

A Ruby symbol is a memory leak. Because of the way Ruby symbols are stored, they can never be garbage collected. So if we create 10,000 one-off symbols that will never use again, will never get the memory back.

from Eric Kidd

I’m sure there are scenarios where this might well be the case, but they’d need to be carefully thought out and measured with real world performance. I would think in the vast majority of cases that leaving these objects sitting around stale in memory is less than optimal.