Provide Scala conversions as both Trait & Object

[tekacs]

With Conversions available as a trait, downstream users can mix the trait into their own extension classes, to minimise imports.

Due to the object Conversions extends Conversions, functionality is unchanged for users who don't want to make use of this.

Usage example:

package somepackage

import org.jooq.Record
import org.jooq.scalaextensions.Conversions

object MyFancyJooqExtensions extends Conversions {
  implicit class ExtendRecordWithSomething(record: Record) {
    ...
  }
}

// in another file...

import somepackage.MyFancyJooqExtensions._ // Conversions are also provided by this import.

Edit: I had to turn the implicit classes into reference (from value) classes - see my note in my second commit about the (should be limited) effect of that.

[lukaseder]

Thank you very much for your suggestion. I remember this practice from the good old Java 1.3 days when I started working with Java:

With Conversions available as a trait, downstream users can mix the trait into their own extension classes, to minimise imports.

Ultimately, this practice has been abandoned once IDE support became better and static imports became available.

Is this really something that is done frequently in Scala these days? I'd really avoid introducing a breaking change for what appears to be an almost negligible improvement...

[tekacs]

In Scala, we tend to import a lot of implicits. As well as this, implicits can't automatically be 'looked up' for import by your IDE (or even in compiler errors) - static imports and IDE support are non-existent here! As such, being able to put implicits in a well-known place is super valuable. 😄

To put that in perspective, when a downstream user or developer on my team is using the DSL, writing:

db.selectFrom(CROISSANTS).where(CROISSANTS.ID === cross.id).one

This is using two sets of implicits - one to provide === and one for .one on the end. In the event that either of these implicits isn't imported, they just get an error and no assistance. They're left to go hunting amongst the imports of other files, trying imports at random until they hit upon the one that provides the necessary implicit (if they're a little smarter, they'll hit 'Go to Definition' on another usage of '===' in the project and import whatever object they end up in).

Perhaps now you can see how valuable it is therefore, to have the developer import:

import model.jooq.DSL._ // our merge/re-export object

and have all the necessary implicits dropped into scope for them, saving them from copy-pasting random imports to make implicits work.

[lukaseder]

Thanks for your explanations. It does make sense, but I still don't feel at ease with the suggestion because:

1. It's not backwards-compatible
2. As an API maintainer, exposing an interface/trait is much more "costly" than exposing a class in terms of what users who implement it might expect in terms of backwards-compatibility

I'll put this on hold to see if there's enough traction for this kind of change in the community to perhaps do it in the next major release.

[tekacs]

Okay - we'll make do with copying the contents out of your object for now and revisit this when you touch it again. :)

[lukaseder]

Yes, that's perfect. Let's hope we'll get more feedback on this, soon!

[lukaseder]

The PR got closed by github due to a recent rename of the main branch.

This issue hasn't seen a lot of feedback yet, and in my most recent comments, I was wary of whether the change was reasonable in terms of backwards compatibility.

I will take the opportunity to keep the PR closed as "won't fix"