-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change to Scala based HOCON config library for JVM #65
Conversation
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.
Exciting! Some small comments, looking forward to see this finally manifest :)
@@ -30,7 +30,7 @@ object TypesafeConfig2Class { | |||
case lst: ConfigList => | |||
Conf.Lst(lst.listIterator().asScala.map(loop).toList) | |||
case _ => | |||
value.unwrapped() match { | |||
value.unwrapped match { |
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 personally don't mind this change, but I would expect a drop-in Scala replacement to not require this diff even if that means using ()
to call non-side-effecting methods
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 really wasn't sure what to do as the internal tests in Scala where inconsistent how it called Java with or without parens. So overall, I tried to make it more Scala-like. I left them on for obvious side-effecting 0-arity methods. Someone who was really bored could do an entire API review 😆
If it really could have been a drop-in then I think Lightbend should have serious considered the PR - it is close but will probably change again for Scala 3 support etc. I also still have to change the package which will require import changes.
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 don't mind the parenthesis diff, metaconfig touches such a tiny surface of the API anyways.
internal tests in Scala where inconsistent how it called Java with or without parens.
with or without parens works when calling Java methods, but Scala "nullary methods" have additional information in their signatures to prohibit calling
will probably change again for Scala 3 support
I doubt that ;) I suspect it will work without any changes.
This PR is very close to being ready!
- change package name so it doesn't conflict with
com.typesafe.config
- new module
metaconfig-sconfig
to avoid conflict with the old one - we can copy-paste the
metaconfig-typesafe-config
tests for sconfig, I hope to remove the typesafe-config tests at some point so duplication is no problem
build.sbt
Outdated
@@ -115,7 +116,7 @@ lazy val core = crossProject(JVMPlatform, JSPlatform) | |||
lazy val coreJVM = core.jvm | |||
lazy val coreJS = core.js | |||
|
|||
lazy val typesafeConfig = "com.typesafe" % "config" % "1.2.1" | |||
lazy val typesafeConfig = "org.ekrich" %% "sconfig" % "0.7.0-SNAPSHOT" |
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 it would be best to create a new module sconfig
and keep the current typesafeConfig
module unchanged.
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.
Agreed. I'll change that once I make a first JVM release. Should I leave the original?
I was pretty excited it actually worked ok to be honest. |
Me too! This is exciting indeed 😄 |
Maybe this is closer to what you were thinking. I didn't change the jvm test dependency in the |
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.
This looks great 👍 Let me merge this now and publish a release.
Thank you @ekrich I agree it's a great first step to migrate the JVM implementation before we do native.
()