David A. Black wrote:

> This all sounds a bit paradoxical: you're suggesting that String be a
> subclass of Symbol (which means that a string would have Symbol's
> instance methods in its lookup path), while symbols would (in effect)
> resort to String's instance methods in the course of trying to resolve
> methods.  That sounds like a kind of two-way inheritance.

Sort-of. The inheritance isn't strictly neccessary for what I am
suggesting. For instance, compare Integers which can be coerced to
Floats, although Float is not a subclass of Integer. But there is a
relationship here b/c one can easily imagine them as such: subclass
Integer and add an attribute for the fractional part. So while the
subclassing is not a must, I suggest it b/c it actually fits into the
overall concept and in this particular case makes a great deal of
sense: Symbols and Strings encode the same kind of data. The sole
difference is in mutability and the methods included.

Hmm.. .let me try to explain that a tad better. I think the fact the
they are readily capable of a class <-> subclass relationship, is what
allows the possiblity of auto-coercion in the first place. If they did
not there would be be no obvious and essentially trivial process by
which to coerce. Does that make sense?

So in a way you are right, it is a kind of two-way inheritance. And if
you think about the orgins of Symbol one can more understand why.
Symbols did not originally exit in Ruby. They were added later as a
light-weight substitute for Strings. So indeed their very existance is
one intended to easily interchange depeding on the usage.

> Which, in turn, means that inheritance probably isn't the solution to
> the problem you're trying to solve.  I don't think I've understood the
> problem yet, though.  The main problem I've seen with strings and
> symbols is a tendency toward excessive conversion; I've often seen
> things like:
>
>    %w{ a b c }.each {|meth| define_method(meth.to_sym) ... }

Although that is a rather direct "abuse" if you will. We are used to
method names being represented a symbols, so we overlook that
#define_methed and the like will handle the conversion for us --But
that is a perfect example of how this type of coercion is already going
on all over the place, only it's being done manually. My premise, and
essentially the problem, is that we are wasting out efforts hadling
this manually when it can be done automtaically, moreover, because of
the extra coding involved one programmer may only support symbols,
another strings. Which means any programmer interfacing two such
systems will have to compensate. And becuase we don't generally see
each other code (assuming good black-box components) we have multiple
to_sym or to_s being applied to the same parameter as it is passed
along --quite inefficient.

> I think there's a somewhat exaggerated sense of the speed-up factor
> involved in symbols sometimes.

That may be the case, but then why have symbols?

Thanks,
T.