A symbol and a variable are two different things. A symbol is
essentially a special kind of literal, just like a number or a string
is. You cannot assign values to symbols, just like you can’t assign
values to numbers or strings – they are their own values. That is, it
makes no sense to say 42 = "banana", just as it makes no sense to
say :banana = 42.
In this case, the author is using the symbol :largecave to represent a
particular location. The reason why he might prefer a symbol literal
to a string literal is that symbols are immutable. “Immutable” means
that you can’t do operations on symbols to change them (unlike, say,
strings). Immutability is a good property because it decreases that
number of surprises you can have, and because it makes reasoning about
your program easier.
Along with what John F. said about symbols’ immutability is the
advantage they have over the string literals that they also often
replace,
and that is the fact that each new instance of a string literal will
refer
to a different Ruby object while each reference to the equivalent symbol
will refer to the same object instance with the added bonus that less
memory
is used. See the example below.
Another way to look at it is a symbol is it is an emnumerated scalar.
I don’t think that’s an accurate characterization, imo, since symbols
have no relationship or knowledge of other symbols. They are not a
collection of anything, and thus by definition can’t be an
enumeration. Using your example, nothing stops you from writing
my_dungeon.start(:bananas)
and that would be a perfectly valid parameter to supply. However, if
you wrote something like
my_dungeon.start(DungeonSizes[:bananas])
that would clue you into the problem. In this case, DungeonSizes would
be more like the enumeration, into which a symbol would be the index
for the element of the enumeration you wanted to select.
Another way to look at it is a symbol is an emnumerated scalar.
You could have
cavesize = 345
my_dungeon.start(cavesize)
However if caves are only ever Small, Medium and Large, then you can
represent that finite set of options by passing :smallcave, :mediumcave
or :largecave.
A symbol can therefore more closely represent the logic of the problem.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.