Em 06-02-2013 16:22, Yorick Peterse escreveu:
>> What I'm trying to say is that the main reason why symbols exist in
>> Ruby in the first place is performance from what I've been told.
> Correct, and your proposed changes would completely nullify those
> performance benefits (see below).
>
>> People reading some Ruby book will notice that it is not particularly
>> designed with performance in mind but it is designed mostly towards
>> programmer's happiness. If that is the case, then worrying about
>> bothered programmers makes sense to a language like Ruby in my
>> opinion.
> So basically what you're saying is "Ruby is written for happiness and
> not performance, lets make it even more slow!". I'd rather see a world
> where Ruby is both fast (enough) and easy to use instead of it being
> easy to use and slower than a sloth.
>
> Regarding the benchmarking information, you're missing a crucial aspect.
> While the numbers in the specific examples I gave both clearly show that
> the use of Strings is substantially slower. Yes, it's "only" 112 kb but
> the difference will keep growing and growing until you hit your memory
> limit.

Man, you're instantiating 50 millions strings and it only increased the 
memory in 112KB. If your application creates so many strings that won't 
be garbage collected then it is unlikely that symbols would help as a 
replacement.

And "growing until you hit your memory limit" is actually only valid for 
symbols, not for strings that are garbage collected already. Unless you 
have some leak in your code that prevent those strings from being 
collected by GC.

> This is exactly one of the reasons Symbols exist: to make it easier and
> faster to use commonly re-used Strings. The best example of this are
> Hash keys.

Most of the programming languages don't support the concept of symbols 
like Ruby. And you won't see C or C++ programmers complaining about this 
neither.

>> This isn't possible when you're serializing/deserializing using some
>> library like JSON or any other. You don't control how hashes are
>> created by such libraries.
> Of course it is. Marshal allows you to store arbitrary Ruby objects
> (with the exception of a few such as Proc instances), in other cases you
> can re-create your objects based on the supplied Hash.

Marshal is not portable across multiple languages (I use both Groovy and 
Ruby in my overall application interacting with Redis). I'm talking 
about JSON here. You don't have to find an alternative to JSON. Just try 
to understand the issue I'm talking about.,

> If you do not like using raw Hashes the solution in my opinion is not to
> more or less re-write Ruby (and break everything that exists in the
> process)

Like what?

>   but instead solve this on your own application level. Using
> Hashie is one example but another one, one I consider far better, is to
> use your own classes. Consider the following:

Ok, I won't repeat myself. Please give an example for the Redis +  JSON 
serialization use case presented in the ticket description.

Otherwise you cleared missed the point.