claps

That’s effen awesome! Three cheers.

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!?”

Cheers!

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

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

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

Rock.

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

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

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.

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

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!

‘Soon’

Potentially deadly…

h = { :symbol => 42 }
:symbol.gsub(/sym/, 'muta')
h
# => ?

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

ok. no worries:

% ./ruby19 -e 'p h = { :symbol => 42 }; p :symbol.gsub(/sym/, "muta"); p h'
{:symbol=>42}
:mutabol
{:symbol=>42}

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 ?

Nice. Not thrilling, but nice.

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

 #ifdef RARRAY_LEN
 #undef T_SYMBOL
 #define T_SYMBOL T_STRING
 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);}
 #else                                                                                                                         
 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;}                                                              
 #endif 

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

Whoa! The gods really are listening! :)

This is a cool change. Sweet and sensible.

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!

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.

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.

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

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

does this mean Symbol < String?

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

Sucky textile (and Preview is broken).

1. Is :foo == "foo"?

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

3. When will the GC reclaim Symbols too?

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.

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

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 .

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?

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.

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#<=>, fine. (Better sort them by name after all Strings, though. I.e. ["foo", :baz", "bar"].sort => ["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).

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!

If

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

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