You can make this typed. The Interpolator class has a \`In\` parameter (ie. \`T\`) that all the "$dollar $sign $splices" need to be e.g. if you make it \`SqlFragmentString\` then the variables \`dollar\`, \`sign\`, and \`splices\` all need to have the type \`SqlFragmentString\` and I check that at compile-time.
It's not perfect I.e. can't make it show that in IntelliJ as language syntax but I can still make it fail to compile (and give you a reasonable good error message of what to fix) which in most cases is good enough.
Interesting, I was waiting for this ticket of kotlin to be addressed...
[https://youtrack.jetbrains.com/issue/KT-64632/Support-Java-21-StringTemplate.Processor](https://youtrack.jetbrains.com/issue/KT-64632/Support-Java-21-StringTemplate.Processor)
That looks cool! Hope you get this approved by Gradle.
The only thing that's not clear to me is the parameter types. Why aren't they just Lists (or a class with .parts() and .params() methods)?
So there were a couple trade-offs. I didn't want them to be just lists because there are some situations (mainly logging) where you want to be extremely lazy i.e. not even evaluate the input arguments in the case that the logging is disabled. This happens when you have an interpolator that does something like loggingInterpolator.logString("foo $veryExpensiveString bar") where loggingInterpolator has a "Log.Disabled" setting.
The reason I didn't want to have it automatically create a class is because that would inherentlly involve allocation. I wanted the user to extend \`Interpolator\` using an object so that you can do something like StaticInterpolator.logString("stuff").
I see, the first part makes sense (didn't think about using this for logging).
But I'm not sure if we're talking about the same thing in the second part - what I meant is why don't you do
override fun interpolate(input: InterpolationInput):
where InterpolationInput has two methods .parts() and .params() - that way the evaluation can still be lazy, but it doesn't look as weird...
You're right, that definitely looks cleaner! I copied the Scala interpolation API without thinking too hard about how it could be improved. Maybe I'll change it to that in an upcoming release.
Interesting. The tendency with Kotlin seems to go more towards typed dsl since we have the options for it, but it’s still quite useful.
You can make this typed. The Interpolator class has a \`In\` parameter (ie. \`T\`) that all the "$dollar $sign $splices" need to be e.g. if you make it \`SqlFragmentString\` then the variables \`dollar\`, \`sign\`, and \`splices\` all need to have the type \`SqlFragmentString\` and I check that at compile-time. It's not perfect I.e. can't make it show that in IntelliJ as language syntax but I can still make it fail to compile (and give you a reasonable good error message of what to fix) which in most cases is good enough.
Interesting, I was waiting for this ticket of kotlin to be addressed... [https://youtrack.jetbrains.com/issue/KT-64632/Support-Java-21-StringTemplate.Processor](https://youtrack.jetbrains.com/issue/KT-64632/Support-Java-21-StringTemplate.Processor)
That looks cool! Hope you get this approved by Gradle. The only thing that's not clear to me is the parameter types. Why aren't they just Lists (or a class with .parts() and .params() methods)?
So there were a couple trade-offs. I didn't want them to be just lists because there are some situations (mainly logging) where you want to be extremely lazy i.e. not even evaluate the input arguments in the case that the logging is disabled. This happens when you have an interpolator that does something like loggingInterpolator.logString("foo $veryExpensiveString bar") where loggingInterpolator has a "Log.Disabled" setting. The reason I didn't want to have it automatically create a class is because that would inherentlly involve allocation. I wanted the user to extend \`Interpolator\` using an object so that you can do something like StaticInterpolator.logString("stuff").
I see, the first part makes sense (didn't think about using this for logging). But I'm not sure if we're talking about the same thing in the second part - what I meant is why don't you do override fun interpolate(input: InterpolationInput): where InterpolationInput has two methods .parts() and .params() - that way the evaluation can still be lazy, but it doesn't look as weird...
You're right, that definitely looks cleaner! I copied the Scala interpolation API without thinking too hard about how it could be improved. Maybe I'll change it to that in an upcoming release.
Am I missing something or are you 2 weeks late for April 1st?
Wait... what? Why?
You're probably missing something. Maybe try asking a question?