Hi --

On Mon, 24 Oct 2005, Trans wrote:

> Speaking of
>
>> i might add that i hope whatever keys object will hash key and symbol
>> arguments the same so we can do
>>
>>    val = keys['foo']
>>
>> or
>>
>>    val = keys[:foo]
>
> Has it ever been considered making String a de-immutablized subclass of
> Symbol? Would this allow for a natural coersion of Symbols to Strings,
> akin to Integer to Float? The above is a common enough occurance. And
> in general I can't think of a signifficant occurance in which I needed
> to distingusih a symbol from a string of the same basic value (ie. :foo
> and 'foo') for the same parameter. I suspect there really is no good
> reason to ever do so --b/c if you are, you're doing something rather
> tricky that probably should be done another way. Of course if anyone's
> got a good counter example please share.
>
> Not that I've fully work this idea through, but I suppose the upshot
> would be two fold:
>
>  1) Certain method could coerce symbol to string when deemed
> appropriate,
>     such a Hash#[].
>
>  2) If a Symbol doesn't respond to a method then coerce to String and
> try that.
>     (Perhaps certain methods would need to be excluded?)

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.

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) ... }

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


David

-- 
David A. Black
dblack / wobblini.net