Em 06-02-2013 17:12, Yorick Peterse escreveu:
>> 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.
> Since existing code (and developers) assume that Symbols are only
> created once they are generally used all over the place without any side
> effects. The moment you start garbage collecting them there's an
> increased chance of the GC kicking in right in the middle of (say) an
> HTTP request. Yes, you may now be able to use both Symbols and Strings
> as Hash keys but you now have to deal with increased GC activity.

You currently already don't control when GC activity begins, so I don't 
understand how this could be considered any disadvantage...

> Note that this of course depends on the code you're using. If you use
> carefully written code that doesn't use Symbols this is not going to be
> an issue. However, pretty every single Gem out there uses them and a lot
> of them also use them quite heavily.
>
>> 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
> C has a goto operator, does that mean Ruby should have one too (I'm
> aware it's already there, it's not just enabled unless you specify some
> compiler flag)? Just because one language has feature X it doesn't mean
> all the others should have it too.

I didn't mean to say that Ruby should take inspiration on other 
languages. My only intent was to show that symbols are not really 
required. But then I remembered that both C, C++ and Java support 
constant strings. In that sense Ruby could just optimize symbols to 
behave like frozen strings and try to optimize that just like the other 
languages optimize their constants.

>> 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.,
> It wasn't suggested as an alternative, merely an example that there is a
> way of serializing arbitrary Ruby data.

I know there are marshaling libraries in Ruby. I just don't understand 
how that is relevant to this ticket.

>> 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.
> Take a closer look at my previous Email, there's a fairly big example at
> the bottom of it that you can't really miss.

I didn't miss it. I just didn't keep it in the reply because it is not 
relevant to my use case.

>   However, just in case:
>
>      require 'redis'
>      require 'json'
>
>      client = Redis.new
>
>      client.set('user', JSON({'id' =>  1, 'name' =>  'John Doe'}))
>
>      # This would happen somewhere else (e.g. an external process)
>      hash = JSON(client.get('user'))
>      user = User.new(hash)
>
>      # instead of user['id'] you can now just do `user.id` which means
>      # that if the key name ever changes you only have to change it in
>      # one place.
>      if user.id
>        # ...
>      end
>

Ok, you missed the point. Let me show you a complete example as I think 
it will help you understanding my concerns (I thought I made myself 
clear in the ticket description, but I hope this code example will help 
you understand what I meant):

require 'redis'
require 'json'
require 'sequel'

cache = Redis.new
users = cache['users'] || begin
   db = Sequel.connect('postgres://user:password@localhost/mydb')
   cache['users'] = db[:users].select(:id, :name).map{|r| id: r[:id], 
name: r[:name]} # or just select(:id, :name).all
end

p users.first[:id]


What will be the output of the code above?

Exactly! It depends! If the results were cached it will print "nil", 
otherwise it will print "1" (or whatever the first id is).

This is the problem that symbols cause because they don't behave like 
strings.

Best,
Rodrigo.