James Britt <james_b / neurogami.com> writes:

> Question: Would using a constant be equally suitable for expressing
> intention, and (possibly) less error-prone?

I would say that if your language does not provide a means for you to
define your own identifier, then it would be acceptable.

But this seems pointless in ruby.


> # Assume ConstUtils.next_value
> # ensures unique values
> HOST = ConstUtils.next_value
> PORT = ConstUtils.next_value

For discussion simplicity sake, I'd just assume next_value returning
integers.

>
> foo1 = {
>     HOST => 'localhost',
>     PORT => 80
> }

p foo1  ==> {32=>"localhost", 238=>80}

That makes debugging difficult. Since the value of HOST/PORT is
volatile (it could change depending on how next_value generates the
integers, and also if you, say, insert 'DOMAIN =
ConstUtils.next_value' between HOST and PORT assignments),
understanding past debugging outputs(e.g., in a log file) would be
harder as well.

> A downside to using symbols as constants is that this will not raise
> any exceptions:
>
>
> foo1 = {
>     :hots => 'localhost',
>     :prt => 80
> }

True, typos are such a hard error to prevent. Fortunately, there are
ways around that.


<example>
module ConfigIdentifiers
       [:host, :port].each{|x| const_set(x.to_s.upcase, x)}
end

include ConfigIdentifiers
foo1 = { HOST => 'localhost', PORT => 80}
</example>

is a solution.

But my experience as someone who has made many typos such as that (and
still is making them) is my test cases usually catch them and those
that manage to elude are easily identified (and corrected) manually.


YS.