wardrop (Tom Wardrop) wrote:

> === Immutable
> A symbol is an alias for a numeric ID. The symbol representation of that
> numeric ID can never change.

As Matthew Kerwin noted, the numeric ID is an implementation detail; and
indeed, the IDs already do change:

$ ruby -e "p [:foo.object_id, :bar.object_id]"
[143928, 144008]

$ ruby -e "p [:bar.object_id, :foo.object_id]"
[143928, 144008]


> === Not garbage collected
> An extension of the previous point. Garbage collecting symbol's would break
> the fact that symbol's are an alias for a specific numeric ID.

Presumably this could only affect programs which retain the object_id
of a symbol past the point where the symbol itself is no longer
referenced by the program, and which then expect to be able to compare
that object_id with the object_id of the equivalent symbol after it
has been GC'd and re-interned.

Assuming the rest of the GC-related problems have been solved, such as
marking any symbols interned by ruby extensions as non-GC-able, then
we should only need wonder how much pure ruby code exists that, during
the lifetime of a given ruby interpreter process, is storing and
comparing symbol object_ids rather than the symbols themselves.

If much such code indeed exists in production environments, then
presumably symbol GC could be introduced as a VM startup option,
eventually becoming the default after the legacy behavior has gone
through a deprecation phase.


It's not evident to me that a solution to the symbol GC issue needs
to be bundled with solution(s) for symbol/string equivalence issues,
however.


Regards,

Bill