[ruby-core:51981] Re: [ruby-trunk - Feature #7792] Make symbols and strings the same thing

Em 07-02-2013 10:04, Matthew Kerwin escreveu:
> On 7 February 2013 20:46, rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
> > I agree that a string is what I want in all cases. That is exactly why I
> > don't feel the need for symbols. If symbols are just really required as
> > a fundamental implementation detail of the MRI implementation, then I
> > don't think it is a good reason to justify keeping them in the language
> > level. Just find other ways to optimize methods/etc lookup in the
> > internal MRI code. This should be a separate discussion from the 
> language
> > design itself.
> >
> > I'd really prefer you to think if symbols are really a good thing to
> > have in the design of the Ruby language if you forget about all
> > performance impacts it might have on the MRI implementation details.
>
> Ok, methods.  They have a bucket of queriable information (a Method 
> instance), and they have a symbolic representation (a Symbol).  I 
> don't want to have to instantiate an entire Method object (or a whole 
> bunch of them) every time I want to talk to an object abouts its 
> methods; I just want a single, simple, universal token that represents 
> that (or those) method(s).

Like a string?

> Sorry, that's a performance optimisation detail.

Before I continue with my arguments and could focus solely on the 
performance issue I'd like to confirm that there is no other reason why 
symbols do exist. If performance is the sole reason and if I can make 
the point that symbols actually degrades most Ruby programs rather than 
improve the overall performance then I can still maintain my hopes for 
this ticket.

> ...
> And for the record: "I don't ever want to use ClassX so let's remove 
> it" is, frankly, silly.

This is clearly not the reason here. That's why I'm asking: what Symbols 
are useful for? Is it performance the only reason why symbols exist?

Symbols cause lots of confusion as I showed in previous examples. That's 
why I want to remove it, but I didn't ask to remove it in this ticket 
anyway. Just to make it behave exactly like strings.

> ...Ok, completely philosphically, without any reference to performance 
> or implementation details, why is a Java enum not equivalent to (or 
> auto-cast to and from) a Java string?

Java, C and C++ have different goals then Ruby. They aim at the best 
possible performance given their constraints. They are also statically 
typed. Enums have two goals in such languages. Improving performance and 
reducing memory footprint is one of them. The other one is to help the 
compiler to find errors at compile time by restricting the input type in 
some functions/methods and variables. I don't really understand how this 
is relevant to this discussion.

> I, too, have been using Ruby for several years now; and I, too, have 
> seen a lot of people wanting Symbol and String to behave the same.  
> Hells, at times even I have wanted that.  But the simple fact is:  
> those people (myself included) are wrong.  If they want a String, use 
> a String.  If they want to force a Symbol-shaped peg into a 
> String-shaped hole, then they'll have to do whatever hoop-jumping is 
> required; exactly as if you want a Java enum to support implicit 
> coercion to and from a string.

I don't want that for Java enums and I don't really understand how Java 
enums relate to the string vs symbols debate in Ruby.

> > People just don't know when to use symbols and strings.
>
> Bingo.  Your solution is: hide Symbols from those people.

Yes!

>  My solution is: don't change anything; maybe eventually enough people 
> will learn that the two classes are, in fact, different.

They won't.

> > Take the Sequel library for instance.
>
> No thanks, apparently the authors don't know the difference between 
> Symbols and Strings.

But I really love the library. Should I really stop using it just 
because it returns an array of hashes indexed by symbols? And Sequel is 
not the only library doing so. Should I stop using all gems out there 
because the authors don't understand they should be always using strings 
instead of symbols in such cases?

You should ask yourself: why are authors so confusing about whether to 
use strings or symbols? Are they all just stupid? Isn't it clear in all 
Ruby books? No, it isn't! It is just really confusing. I'm yet to read 
some book that does a strong argument whether you should be using 
symbols or strings. They just say that symbols perform better than 
strings so authors think: "hey, then I'll just use symbols everywhere 
and my gems will perform the best possible way!". But this thinking is 
plain wrong because you'll need extra steps for conversions among those 
types very often. The fact is that most authors don't really care about 
symbols or strings at all. They don't spend their time thinking about 
whether they should be using symbols or strings. They don't WANT to 
worry about it! And they're not wrong! Since they don't want someone 
looking at their code and telling them that their gem could perform 
better if they used symbols instead of strings they will just use 
symbols everywhere! This reality won't change. That is why I think 
programmers shouldn't have to worry about any performance difference 
that might exist between using symbols or strings in their code.

If there is a real boost using symbols internally in MRI then this 
should be an implementation detail only, not exposed to Ruby programs. 
That is why I suggested the optimizations to care if the string is 
frozen or not (like other compilers will optimize constants) instead of 
creating a new concept (symbols) just for that. They could keep the 
:symbol syntax as an alias to 'symbol'.freeze.

> ...
> > I'd prefer that you focus on explaining why you think keeping symbols a
> > separate beast is of any usefulness
>
> I'll choose to interpret that as "... why I think keeping symbols at 
> all ...".  Simply: because they're already here.

This is not a good argument in my opinion. If you want to keep the 
syntax :name as an alias to 'name'.freeze I believe most current Ruby 
programs wouldn't be affected by such change.

> ...  Personally I've never used HashWithIndifferentAccess, or needed to.

Me neither. But for different reasons. I need the behavior but I don't 
think it worths the extra dependencies in my code (ActiveSupport) nor 
the cumbersome of writing such a big class name everytime I want my hash 
to behave like HWIA. I prefer to take some time to investigate if all my 
hash keys are really strings than to just instantiate HWIA all over the 
places.

> Incidentally those people don't want a Hash at all.  They want an 
> associative array, one that uses something like <=> or === to compare 
> keys (instead of #hash and #eql?).

:a === 'a' is not true so I don't understand how such suggested 
associative array would help here.

> ...
> This is true of _any_ issue in a library.  If you think the library's 
> benefits outweigh its costs, then you use the library.  If the fact 
> that the authors erroneously conflate Symbols and Strings is 
> outweighed by the fact that it's otherwise extremely useful, it's up 
> to you to work around the shortcomings.  Just like if some otherwise 
> brilliant library uses 0 instead of nil, or something.

Again, please don't pretend that the confusion between strings and 
symbols are similar to confusions between 0 and nil.

> The general syntax served us well enough through 1.8 and 1.9.

Actually I never liked writing hashes as {key => value} in all years 
I've been working with Ruby. But I won't stop using Ruby just because I 
don't like its hash declaration syntax just the way I won't replace 
Sequel just because they return hashes indexed by symbols instead of 
strings.

> ...
> > The difference is that in the other languages a string is used since 
> they don't have the symbols concept.
>
> That's a good point.  I'd love to be able to change the new syntax so 
> {a:1} meant {'a'=>1}, but that's not going to happen.

I agree it is unlike to happen. What about another syntax: {{a: 1}} => 
{'a' => 1}? Maybe it would worth trying to ask for some syntax change 
like this one. We could even add interpolation to it: {{"value 
#{computed}": 1}}.