ruby-core

On Jan 28, 2008, at 10:09 AM, Gary Wright wrote:

>>> String#to_sym is a guaranteed 'perfect' hash though, not a regular  
>>> hash with possible clashes.  If Symbol/String aren't going to  
>>> provide that functionality then someone is going to immediately  
>>> write a gem/extension that does.
>> Here a I was meaning a Hash object, not to_hash.
>
> You were talking about 'the works of Shakespere' as a symbol, which  
> I assumed meant the mapping of an arbitrary string to a smaller  
> value for fast comparisons.  That isn't a Ruby Hash object it is a  
> mathematical hash function.  So I guess I just don't understand what  
> you meant by that example.

Gary:

Let's assume that I know what a Ruby Hash is... :)

If you really want to map arbitrary strings to some other value, then  
you can use a Hash to manage that

class StringToInt
   def initialize
     @contents = {}
   end
   def lookup(val)
     result = @contents[val]
     unless result
       result = @count += 1
       @counts[val.dup] = @count
     end
     result
   end
end

So, my point is that for the rare times you're looking for a string-to- 
identity function, you can write one trivially. There's no need to  
burden the language with it. However...

>> I just don't see the need to burden the language with a complex  
>> feature with dubious semantics to implement a little used feature  
>> that can be implemented trivially using existing constructs. So, I  
>> agree with you--a gem is where this belongs.
>
> How can a 'complex feature' also be implemented 'trivially'?

Implementing something that adds complexity is easy... It's normally  
harder to implement something that's elegant.

Look at it another way. If you implement it at the application level,  
then it's just some application thing, and it doesn't have an impact  
on the language semantics. It isn't tied to the abstraction of "a  
symbol."

However, it you declare that Symbols are not really symbols in the  
symbol table sense, but instead are now some kind of half-string, then  
you are introducing lots of complications, because now you're changing  
the semantics of the language, and introducing new stuff that  
interacts with other areas of the language. These interactions are  
hard to predict.

One of the joys of Ruby is discovering unanticipated interactions.  
Symbol.to_proc is a good example. However, in this case, I don't think  
that we're looking at anything magical coming down the pike. I just  
think we're adding to the surface area of the language without  
significantly enhancing the functionality.

> How can you provide the string literal notational convenience with a  
> gem?

Why do you need it for anything apart from :symbol, which the language  
already supports. If you do need it, it's a method call. Most gems  
implement their functionality with method calls--no one complains that  
Builder doesn't integrate with less than and greater than to support  
<name>Dave</name>.

> How can you avoid the per object overhead of a full instance of  
> Object?

Symbols are objects too. When you write :"war and peace" you're  
creating a Ruby object (the symbol) and you're storing the string "war  
and peace".  (And, talking of overhead, in 1.8 symbol contents could  
not be garbage collected, whereas string contents could.  
File.read("big_file").intern will permanently use up the memory that  
holds the file's contents. The same seems to be true of 1.9, but I may  
be mistaken.)

> Do you really think that String#to_sym is 'little used'?

For arbitrary strings, I do. For things that are true symbols,  
obviously not.

I see exactly what you're saying, and understand why. But I just don't  
see how :"some arbitrary string" or File.read(...).intern will ever be  
used enough to justify the additional complexity in the language.

Dave

Thread

Prev Next

In This Thread

Prev Next