Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
replace pimp with 'rich', 'enrich', 'extension method'
and: * add MiMa so we know the change is binary compatible * use current Scala & sbt versions
- Loading branch information
Showing
8 changed files
with
49 additions
and
18 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
sbt.version=0.13.9 | ||
sbt.version=0.13.16 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7089839
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the future I would like to ask that breaking changes to the API interface involve more than a bugfix-level point change or at least a migration guide or changelog change to document that the change is breaking.
Specifically, this removal:
and replacing it with:
Meant that any code that depended on the
implicit
broke.I like the renaming, definitely +1 for that, but the break was a bit jarring, especially with no documentation on what changed/changelog/notification.
7089839
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dclements the deprecated implicits were replaced with new implicits that just have a different name, so we expected that the change would be source compatible for 99% of users, since we thought basically nobody would have cause to refer to the old implicits by name.
and leaving the old methods in place, minus
implicit
, should have ensured that the change was binary compatible.I don't understand why that would be. What broke for you? I'd like to understand this better. The change was intended to be 100% binary compatible, and source compatible for nearly everybody. Did we screw it up?
7089839
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that there's an implicit (heh) assumption that people using the library will import implicits by
_
and not by name, but frequently in order to bound the scope or for style guide reasons just the name is imported (e.g., IntelliJ has aClass count to use import with '_'
setting inEditor > Code Style > Scala
). This means that a lot of the time when importing implicits the scope is going to be bound by a combination of location (which isn't a problem here except in that it means fewer imports so editors are less likely to use_
) and/or specificity (which is why it broke for me) .To make this concrete about my use case, let's say that I have a JSON string:
Previously to convert foo to json I would call
Which now breaks.