Hi --

On Mon, 5 Dec 2005 gwtmp01 / mac.com wrote:

> > To my knowledge there's no programmatic access to the underlying
> > symbol
> > table in Ruby.  (Am I wrong about this?  Have I missed all the
> > table-manipulating fun? :-)
>
> When you define an instance method you are adding an entry to the
> method table for the class.  The key for this table is a symbol so
> you might be implicitly adding an entry into the internal table
> of all symbols (maintained by the Symbol class).  When you call
> method("puts") or send("puts") you are looking up an entry in the
> method table. When you call remove_method("puts") you are deleting
> the entry in the method table. Same situation for constants (which
> implicitly
> means Modules and Classes). This is what I meant by symbol table.

I understand -- but what I meant was, there's no situation where you
directly do:

  the_symbol_table << :sym, method(:x) # homemade 'alias'

or

  the_symbol_table.each_row do { ... }

In other words, you don't address the table as a tabular data structure
programmatically.

> > Again, I think that from the programmer's perspective, you can map
> > from
> > strings to methods just as easily:
> >
> >   attr_reader :a
> >   attr_reader "a"
> >   attr_reader :a.to_s
> >   attr_reader "a".to_sym
>
> Yes, it is this mapping from strings/symbols to methods that is novel
> for many programmers.  I think it is the novelty of this built-in
> mapping ability that gets confused with the abstract-data-type aspect
> of Symbols.

I would separate the concerns.  The reflection/metaprogramming stuff in
Ruby isn't really about the Symbol class.  So you could, as JEG3 suggests,
describe them principally as an immutable (and quickly resolvable) string
variant.


David
__
David A. Black
dblack / wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!