Re: "consuming" the hash instead of just fetching from it

2009/5/22 Markus Schirp <[e-mail]>:
> On Fri, May 22, 2009 at 08:10:09PM +0900, Balint Erdi wrote:
>> Hi,
>>
>> Deleting (vs. just fetching) the hash key from an options hash that
>> was passed in as an argument to the method seems prevalent. I saw it
>> in several high-quality OS projects (e.g DataMapper, Rails)
>>
>> For example:
>>
>> unless options.delete(:only_path)
>> =A0 =A0 =A0 =A0 url << (options.delete(:protocol) || 'http')
>> =A0 =A0 =A0 =A0 url << '://' unless url.match("://")
>> =A0 =A0 =A0 =A0 ...
>> end
>
> This snippset let you test on "mispelled" or "extra" opts:
>
> Example:
>
> def initialize(opts)
> =A0@a =3D opts.delete(:a) || raise("missing :a")
> =A0@b =3D opts.delete(:b) || "b"
> =A0raise "unkown options: %s" % opts.keys.inspect unless opts.empty?
> end

You can have that with the non deletion approach as well.

I agree to what Robert said: this should be carefully inspected.
Generally I would refrain from changing an argument, especially if it
is some global options object.  These options might be needed in other
places as well and if they are modified by code other than the option
parsing (or reading) process then chances are that something will
break.  For example, consider two places in code which need to react
on the same option value then only one of them gets the value with the
"delete pattern" and even worse, things may accidentally work
initially but break if initialization order is changed.

Also, if the options instance is frozen after being filled by option
parsing or reading process the delete approach won't work any more.
As a general rule of thumb it is safer to not modify option arguments.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/