Call #to_s on output to avoid leaking Differ's implementation details.

[phiggins]

Prior to this, the output of Differ.diff was an EncodedString if the arguments were diffable. An EncodedString mostly acts like a String, but nothing outside of Differ needs to know it exists.

[fables-tales]

@phiggins I can see why this would be useful. @myronmarston @xaviershay @JonRowe got any objections? @phiggins did this directly cause a bug? If not we'll almost certainly not be merging this until after 3.0 gets released.

Thanks for the PR! 😄

[JonRowe]

I agree we shouldn't leak this but I'd prefer we did the #to_s at the last moment, which probably means where it's used and not here, reasoning being this is part of our API and we might legitimately want to use the EncodedString outside the differ.

[phiggins]

@samphippen No, I just noticed it when working on adding diff support to rspec-mocks and debugging output.

[phiggins]

@JonRowe I'm not sure I understand your reasoning. It seems bad to me that Differ.diff can return two different types in different circumstances, but if you're ok with the return value being "string-like" then this can be closed.

[fables-tales]

@JonRowe I definitely think it's better not to leak the EncodedString out of differ space. Otherwise other people have to be aware that EncodedString exists, as opposed to this object.

[myronmarston]

I like this change, and agree with @phiggins that it seems preferable to always return a string. EncodedString feels like an internal implementation detail to me and not something that clients of rspec-support should be aware of.

[JonRowe]

@phiggins say we decided we wanted to state the encoding types in the output, the ideal place to pass this information about would be with this class, we could decide this is a public api and pass it back to formatters for similar reasons, so for now if we are going to truncate this down into a string I'd rather it was done at the endpoint and not here

[myronmarston]

@phiggins say we decided we wanted to state the encoding types in the output, the ideal place to pass this information about would be with this class, we could decide this is a public api and pass it back to formatters for similar reasons, so for now if we are going to truncate this down into a string I'd rather it was done at the endpoint and not here

If we want to make EncodedString public and do that at some future point we can. Choosing to return a string for now doesn't prevent us from doing things like that in the future.

[fables-tales]

I agree with @myronmarston and @phiggins

[myronmarston]

Merged. Thanks, @phiggins.