has_many :bugs, :through => :rails

I like the first since it uses the full case idiom where target variable id is not repeated in each when clause. Implicit is that the target variable to case is evaluated for equality to each thing held in each when clause until equality is found (or else not). However the example given the equality of items being evaluated is coupled to the kind of class they are.

In the second duck typing example equality expressions are explicitly placed into the when clauses. Again, the target variable id is repeated over and over as well as the equality symbols. However since its doing duck typing (i.e. what can the object do rather than what it is) the evaluations are coupled to the interface exposed by the object, not by its class type.

Yes, choose whats’ best for the situation, don’t use one or the other as a golden hammer.

def self.user_klass_for thing
  case thing
  when Class   : thing.to_s
  when Profile : thing.user.class.to_s
  when User    : thing.class.to_s
  else thing.to_s.classify
  end
end

I think it is still possible to practice duck typing, and use a case statement.

Looking at your example, I think this sort of thing with :first etc is implementing some kind of interface, so it’s pays off later if we make it robust now. So duck typing it is a few more chars, requires a little more planning, but lets us lay in the sun sipping lemoncello later, because it’s so easy to use! Quakc quakc quack

def amazing(id)
  begin
  case
    when id == :first : "first post!" 
    when id === :all : "one two buckle my ===" 
    when id.integer? rescue nil : id
    when id.respond_to?(:to_str) : "No discrimination against foreign strings" 
    else !!id
    end
  rescue
    warn "Calling people jerks is meanypants!" 
  end
end

And it’s probably not even all that hard to read. I wouldn’t advocate #’s 1,2, or 3 in the post. They all have issues.

I don’t see how being against duck typing somehow makes you the defender of free thought against the tyranny of common Ruby concepts. The important thing that your examples neglect is that however you implement your duck typing, your method should accept data that it can reasonably use. So at least add a useful else that tries to quack. No need to kill the duck you were handed, just because it had unfamiliar plumage.

I never said I’m against duck typing. But for me, readability of the code comes first. Checking for type instead of behavior would make sense in many cases. My whole debate is against, labeling checking of type as “non ruby” way of doing things.

May be you should read what matz has to say

Uhmm… the first example is duck-typed too you know… :) At least parts of it are. And since it’s language-integrated, threequals seems to deserve it’s own category no? I mean, it’s a bit of a hybrid.

You could easily do something like:

class Symbol alias r_threequals === def ===(arg) arg.respond_to?(self) || r_threequals(arg) end end

p case ‘bob’ when :to_i then ‘sweet’ when String then ‘ok’ when nil then ‘meh’ end

I agree about readability, but honestly, you know you were cheating. ;) Even if you wanted to use #respond_to? directly, there’s no reason to turn every other when…then into an explicit equality call.

hello

i am beginner for rails tutorials please tell me how to create session management in rails2.0. give some code for creating session management.

Thanks, Ranjan.