hoodwink.d enhanced


:symbol.is_a? String #

by why in inspect
 => "1.9.0" 
 >> sounds = {:ka_ching => :money, "br_rr_ring" => :phone, 
      "phil_l_lip" => :nose}
 => {"br_rr_ring"=>:phone, "phil_l_lip"=>:nose, :ka_ching=>:money}
 >> sounds["ka_ching"] = :cash
 => :cash
 >> sounds
 => {"br_rr_ring"=>:phone, "phil_l_lip"=>:nose, :ka_ching=>:cash}
 >> sounds[:'br_rr_ring']
 => :phone
 >> :symbol.is_a? String
 => true

Goodbye, HashWithIndifferentAccess. I feel toward you the same you feel toward your lookups.

 >> :symbol.gsub(/sym/, 'muta')
 => :mutabol
said on 05 Sep 2006 at 12:32


said on 05 Sep 2006 at 13:02

That’s effen awesome! Three cheers.

said on 05 Sep 2006 at 13:07

That’s brilliantly clever! I guess that’s why we call you _Why… because we always ask ourselves “Why didn’t I think of that, damnit!?”


said on 05 Sep 2006 at 13:09

Now we’ll never be able to explain the difference between symbols and strings to noobs! :)

said on 05 Sep 2006 at 13:19

Dr Nic: Except, now we can say a symbol is just a frozen string.

 >> "panther".gsub! /pan/, 'gun'
 => "gunther" 
 >> :gunther.gsub! /gun/, 'pan'
 RuntimeError: can't modify frozen string

The simple rule then being: you can call a panther Gunther, but Gunther can’t be a panther—he’s frozen under a sheet of ice.

Also: In case you were wondering.

 >> "panther".object_id
 => 68085330
 >> "panther".hash
 => -476157353
 >> :panther.object_id
 => 68074330
 >> :panther.hash
 => -476157353
said on 05 Sep 2006 at 13:38

Oh! with that further explanation, I would have to say three, maybe four cheers!

said on 05 Sep 2006 at 14:18


Matt: Although very cool, it’s been done this way before; see Smalltalk for example. :-)

said on 05 Sep 2006 at 14:29

Oh, no, uh, this is Matz’ hack, guys.

said on 05 Sep 2006 at 14:43

Ulysses: It’s all been done before in either Smalltalk or Lisp. I don’t think anyone’s come up with any significantly new programming paradigms in years. That doesn’t mean it isn’t a good idea to incorporate those ideas into Ruby or any other modern lang. Those old bearded guys knew what they were doing. New language creators just tend to ignore/forget/be ignorant of/not have time to reimplement the lessons of their predecossors.

said on 05 Sep 2006 at 14:51

Finally, a Symbol really is just an interned String :)

said on 05 Sep 2006 at 15:26

Well this is just awesome, now all the code I wrote for dealing with this problem is going to be unnecessary soon. Yay for less code!

said on 05 Sep 2006 at 15:45


said on 05 Sep 2006 at 16:08

Potentially deadly…

h = { :symbol => 42 }
:symbol.gsub(/sym/, 'muta')
# => ?
said on 05 Sep 2006 at 16:09

Hey, wow, this is like ten kinds of okay! Good work matz!

said on 05 Sep 2006 at 16:12

ok. no worries:

% ./ruby19 -e 'p h = { :symbol => 42 }; p :symbol.gsub(/sym/, "muta"); p h'
said on 05 Sep 2006 at 16:13

So, really, symbols ARE just lightweight strings now :) This gives us something else to talk about at our RoSL meeting on Thursday. 1.9 is shaping up to be a really cool release. Where be the CHANGELOG ?

said on 05 Sep 2006 at 16:26

Nice. Not thrilling, but nice.

said on 05 Sep 2006 at 17:29

okay, matju has some defs, if anyone’s code is straddling.

 #ifdef RARRAY_LEN
 #undef T_SYMBOL
 static inline long  rb_str_len(Ruby s) {return RSTRING_LEN(s);}                                                               
 static inline char *rb_str_ptr(Ruby s) {return RSTRING_PTR(s);}                                                               
 static inline long  rb_ary_len(Ruby s) {return  RARRAY_LEN(s);}                                                               
 static inline Ruby *rb_ary_ptr(Ruby s) {return  RARRAY_PTR(s);}
 static inline long  rb_str_len(Ruby s) {return RSTRING(s)->len;}                                                              
 static inline char *rb_str_ptr(Ruby s) {return RSTRING(s)->ptr;}                                                              
 static inline long  rb_ary_len(Ruby s) {return  RARRAY(s)->len;}                                                              
 static inline Ruby *rb_ary_ptr(Ruby s) {return  RARRAY(s)->ptr;}                                                              
said on 05 Sep 2006 at 18:56

Yuck. Too bad if you previously relied on the two not being equal.

said on 05 Sep 2006 at 19:20

Whoa! The gods really are listening! :)

said on 05 Sep 2006 at 19:38

This is a cool change. Sweet and sensible.

said on 05 Sep 2006 at 19:51

Is this only in the latest versions? I run Ubuntu and loaded the version of Ruby 1.9 listed in the repositories and none of these fun tricks worked. :/ Me want! Me want!

said on 05 Sep 2006 at 20:56

Trejkaz: Just switch your checks to useobj#object_id— strings and symbols are still distinct objects, they are just permutable now. Identity is preserved, it’s just that equivalence is introduced.

said on 05 Sep 2006 at 23:18

The more I think about it, the more I’m worried about this change. Wouldn’t it have been easier to modify Hash#[] and Hash#[]=?

Let’s face it, that covers 99% of the use cases we’re actually solving with this change. For the remaining 1%, you’ve saved me from the horror of a .to_s call.

I guess I’m just worried this is going to bite us in the ass down the road somehow. I don’t know how yet, but the feeling is nagging at me.

said on 06 Sep 2006 at 00:35

Alreadyalias_method,define_method,method and so forth accept either symbols or strings (internal conversion as needed). It just makes sense to extend that all the way down the line to hash indicies and so on; makes sense to me anyhow, but then I’m relateively dumb. ;)

said on 06 Sep 2006 at 01:13

Does this make string handling any faster? I heard Python had faster strings because tehy are immutable there…

said on 06 Sep 2006 at 05:38

does this mean Symbol < String?

said on 06 Sep 2006 at 07:14

1. Is :foo "foo"? 2. Is :foo = “foo”? 3. When will the GC claim Symbols too?

said on 06 Sep 2006 at 07:19

Sucky textile (and Preview is broken).

1. Is :foo == "foo"?

2. Is :foo === "foo"?

3. When will the GC reclaim Symbols too?

said on 06 Sep 2006 at 10:30

As cool as I think this will be for slimming down the api, and getting the hashwithindifferentaccess stuff removed from rails, it still feels very wrong to me.

I’d love to provide a reason but at the moment nothing comes to mind.

I guess for now I’ll say I’m happy about it.

said on 06 Sep 2006 at 10:50

murph: No, we’ll still have mutable strings. I don’t know about speed though.

J`ey: Ehh… yesbutuntil the GC can reclaim Symbols, I definitely would not use Symbols in place of frozen strings—you’ll {fill up the symbol table,shoot your eye out}.

said on 06 Sep 2006 at 12:17

So, Matz cites four reasons for this decision:

  1. The spread of ActiveSupport has increased the need for strings and symbols to be united as hash keys.
  2. To address RCR 342 , which would allow sorting of symbols. (Try: Symbol.all_symbols.sort.)
  3. Smalltalk’s symbols are a subclass of string. (He adds that this is his most motivating reason to do it.)
  4. Using symbols as immediate values can cause them to venture into pointer territory, particularly on OSX .
said on 06 Sep 2006 at 13:58

So, _why, out of curiousity are you actually able to read japanese? Or do you just use some translator to read all of the useful stuff from our cousins?

said on 06 Sep 2006 at 19:17

Nicholas: _why is actually about 20 people, 13 of which are Japanese. How else do you think a mortal could be so productive and good at so many different things.

said on 07 Sep 2006 at 05:44

I think this is a bad decision.

You can make Symbol a subclass of String, however :foo must not be == to “foo”. It not only breaks a lot of code in tricky ways, it also takes the possibilty to use Symbols as “special case” values.

With respect to the arguments by matz:

1. If people would code consistent, they either use only Strings as keys, or only Symbols; or they mix them and need to be careful (there can be useful cases for this!). HashWithIndifferentAccess looks more like a code smell to me.

2. You can add Symbol#&lt;=&gt;, fine. (Better sort them by name after all Strings, though. I.e. ["foo", :baz", "bar"].sort =&gt; ["bar", "foo", :baz])

3. This is ok. But don’t break == (and ===).

4. That sounds more like trying to avoid fixing bugs (I thought it had been fixed, even). But it’s ok too. It doesn’t even imply (3).

said on 07 Sep 2006 at 05:56

I just saw this change. I guess that fixes the issue appropriately. It’s just a bit unfortunate that (:foo == "foo") != ("foo" == :foo), but I can live with it.

Thanks, matz!

said on 07 Sep 2006 at 13:50


1.method(:+) == 1.method('+') # => true</cod>


<code>:+ == '+' # => true</code>


Shouldn’tObject#equal?orObject#object_id be used to find the difference of identity between the symbol and string version of +, rather than==or===?

said on 07 Sep 2006 at 14:36

great decision ;-)

said on 07 Sep 2006 at 14:46

masukomi: Of course—before this change our symbols were taken from lisp; (They can be converted to and from strings, but they’re not strings) whereas now they’re taken from Smalltalk. I for one welcome the change of parentage.

11 Jul 2010 at 21:11

* do fancy stuff in your comment.