Closed DenialAdams closed 9 years ago
Problem here is that I think the default implementation of .eql?
will compare the actual object instances. The gem currently generates a fresh new Song instance every time you call #status
, so even if the song hasn't changed, .eql?
will fail, meaning we're going to trigger the callback on every loop iteration.
The solution instead is to edit the ==
method on the Song model to also include title
:
def ==(another)
+ self.class == another.class && self.file == another.file
- self.class == another.class && self.file == another.file && self.title == another.title
end
Ah, got it. Sorry for missing that, I got a bit too excited... What if just the artist changes, for example? Or some other piece of metadata? Although it seems extremely extremely unlikely the title would stay the same but the artist changes
Good point! Hmm, maybe we could implement the .eql?
method then, which casts both songs to_h
and compares the hashes?
That solution seems perfect! Great idea.
Would you like to implement that or should I give it a go?
You can update this PR and I'll get it merged and released to rubygems
How does that look? Hope it's ok, I'm not very used to contributing to other code bases >.<
Just my $0.02: I'd rewrite the implementation of the ==
method itself and alias eql?
like the following:
def ==(another)
to_h == another.to_h
end
alias :eql? :==
Ah! That seems better, as long as nothing is relying on the behavior of the current == (same file)
Also, I've had a similar solution in my local branch that I was planning on pushing up at some point but I have to admit that I find the suggestion above much more elegant and idiomatic. It's great to see ruby-mpd
improving and having other peoples' continued support. \o/
Ah, thank you very much ^^
@AStrangeEnigma cheers! Can you please squash these commits, then I'll merge?
There you go! Thanks, I was not aware about squashing commits prior to this :)
Released as v0.3.3 :)
for callbacks. From the issue thread:
I did some digging and I think I found a rather smooth solution to this issue! The thing is, the MPD song details change when the radio track changes but comparing the songs with == returns true - even though the object has changed! Consider this:
So, if we used .eql? or .equal? (I am not exactly sure which one is better) instead of == at https://github.com/archSeer/ruby-mpd/blob/master/lib/ruby-mpd.rb#L228 then the MPD song callback would trigger when the track in a stream changes. I think this change makes a lot of sense. My only concern is that it might cause unexpected behavior with other callbacks (although I doubt it) but we should test and make sure everything still works as expected.
Also, I checked the refactored version in #32 and it seems that it would need to be changed in the same way.
Thanks, let me know what you think!