1. 2
  1.  

  2. 2
    def anagrams(subject, candidates)
      candidates.each do |candidate|
        subject != candidate && same_alphagram?(subject, candidate)
      end
    end
    

    Ahhh, you’re going at it wrong mate.

    Don’t go looking for a Candidate class

    Look for an enumerable container of candidate, and subject that is is comparable (!=) to a candidate.

    And do a similar duck type analysis of same_alphagram?

    ie. Stop looking for types, look for collections of methods. Subtly different.

    1. 1

      That is the functional notion of a type though. I think this is a true difference between the object-oriented and functional worldview; I wrote some thoughts at http://m50d.github.io/2014/12/08/object-oriented-essentialism.html

    2. 2

      If you think types are important, Ruby might not be where you want to spend your time. I know that sounds like “oh another type snob”, but really, I’m working on a Python project now and I’m a big fan of static types and it’s rather miserable. The trick and assumptions I’m used to making don’t work and the ways I design my programs not very usable, or horribly awkward. If types are important, then hanging out in unityped language is probably a good way to write bad code.

      1. 1

        How about something like:

        def anagrams(String subject, String[] candidates)
        

        Lets you immediately understand what types the function expects. Just too bad a lot of languages don’t have a good way to convey that information.