The Ruby convention is for Class and Module instances to be open. Immutable Equalizer instances breaks this convention.

Virtus::ValueObject.attribute is an example where an Equalizer instance can/should be mutable.

Since all the attributes of an Equalizer can be assigned in the constructor, I think it remains elegant to put the burden of immutability on the user:

class MyThing
  include IceNine.deep_freeze(Equalizer.new(:the, :keys))
end

Hi,

Currently equalizer only triggers when include'ed into a Module, I have a use case that fails with this assumption, here it is.

I only want the equalizer functionnalities for some objects, not all object of a class, so I define the equalizer like this:

  GeoLocationEqualizer = Equalizer.new(:latitude, :longitude)

The class like that:

  class GeoLocation
    attr_reader :latitude, :longitude

    def initialize(latitude, longitude)
      @latitude, @longitude = latitude, longitude
    end
  end

And the code using them:

  restaurants = get_locations_from('http://example.com/paris/restaurants')
  cafes = get_locations_from('http://example.com/paris/cafes')

  # I'm interested in comparing location only for those objects, extend them
  restaurants.each { |restaurant| restaurant.extend(GeoLocationEqualizer) }
  cafes.each { |cafe| cafe.extend(GeoLocationEqualizer) }

  # I want to know which cafes are on the same location as restaurants
  # (Array#& uses eql? and hash)
  matching = restaurants & cafes

In the current code, the Methods module is not mixed in when extend'ing objects.
For that we have to add the extend_object hook like this:

  def extend_object(obj)
    obj.extend Methods
    super
  end

May this be added to master? Should I submit a PR?

Regards

Not sure why but I had to explicitly add adamantium dep even though equalizer depends on it and it's specified as a runtime dep in the gemspec

Can we bump to 1.0.0 and release?

When using Equalizer in projects that use YARD for documentation, YARD raises a YARD::Parser::UndocumentableError on every line that mixes-in Equalizer.

I’m not sure exactly how to solve this problem. Maybe I should just silence the warnings in YARD or maybe Equalizer should change its interface to mix-in a static module and then use class methods to define which attributes to use for equality. For example:

class GeoLocation
  include Equalizer
  attr_reader :latitude, :longitude
  equalize :latitude, :longitude

  def initialize(latitude, longitude)
    @latitude, @longitude = latitude, longitude
  end
end

I’m interested to have some discussion around this issue.

/cc @lsegal

I have an object which defines a #coerce instance method as part of its public API. I didn't realize until recently that this breaks #== for this object and all of the objects that own it until today.

I understand after talking to @dkubb that this is a weak convention in ruby, but it might make sense to deprecate the use of #coerce and instead depend on a method that is less likely to naturally collide with unrelated method names that are not meant for equalizer

Hi,

I suppose this error is not intentional behavior?

require 'equalizer'

class GeoLocation
  include Equalizer.new(:latitude, :longitude)

  attr_reader :latitude, :longitude

  def initialize(latitude, longitude)
    @latitude, @longitude = latitude, longitude
  end
end

point_a = GeoLocation.new(1, 2)
point_b = GeoLocation.new(1, 2)

point_a == point_b # true
point_a == Object.new # NoMethodError: undefined method `latitude' for #<Object:0x00000001c91728>

BTW. Awesome trick with the module subclassing and instantiation. I've never imagined this is possible and used my own monkey patch. https://gist.github.com/4252597

What if we have Foo that includes an equalizer and then have Bar < Foo that includes another one? Do you think we should support that automatically? As in, should it "merge" those equalizers together in the inherited hook?

Heya, thanks for equalizer!

Was debugging a performance issue today and noticed that ~25% of the request time was taken up by repeated calls to equalizer's #hash method when I was using an equalized value object as a hash key. It also appears that ~60% of that ~25% was calling #to_proc on method(:send), so caching the proc'ed send in a constant or something may help. As a comparison, switching to using a stringified version of my value object as the hash key was relatively free... i.e. subsequent requests sped up by ~25%.

Not a deal breaker, just a heads-up. Attached a screenshot of the flamegraph in case it helps.