-
Notifications
You must be signed in to change notification settings - Fork 289
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
Move Java reflect specific extensions into a separate package #299
base: main
Are you sure you want to change the base?
Conversation
@@ -15,6 +15,7 @@ | |||
*/ | |||
package com.squareup.kotlinpoet | |||
|
|||
import com.squareup.kotlinpoet.jvm.asClassName |
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.
These imports will disappear when the factory methods that use them are moved into "jvm"
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
@file:JvmName("ClassNamesJvm") |
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.
Ideally that should remain as "ClassNames", but there's the KClass<*>.asClassName()
function that stays in the main module and Java clients that need methods from both versions will have to use fully-qualified class names. Maybe there's a better way.
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.
How about @JvmMultifileClass
and the same @JvmName
?
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 doubt it'll work across multiple modules, but I can give it a try
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.
There won't be multiple modules. You'll have the common module with common code and then the jvm module will implement the common module and add JVM-specific things. There will only be one class file in the final artifact. And then for JS there will be a JS module, etc., and they're free to have platform-specific things as well.
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.
Oh, I see. Didn't think about it from the perspective of cross-platform modules, rather that kotlinpoet-jvm
will just provide extensions for kotlinpoet
. I'm curious to try the cross-platform approach.
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.
Yeah the nice thing about using multiplatform rather than multiple modules is that you pick one artifact based on the platform on which your code generator runs. And if your code generator is multiplatform, then you only get the common stuff.
If we can do multifile classes for now let's do that. If we end up doing two artifacts it's an easy change to make.
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
@file:JvmName("WildcardTypeNames") |
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.
Should all of these just be a single class, JvmTypeNames
?
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.
(and a single .kt
file?)
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.
That's a good idea!
@Egorand status on this? |
I wanna do #304 (multiplatform project), based on the learnings from Okio. Will keep this around for some time and then close. |
Is this abandoned? Is there any way to use kotlinpoet to generate kotlin used by multiplatform modules? |
That has always been possible. This ticket is for running KotlinPoet itself in non-JVM contexts. |
That's the first part of #157. Next step is to move all factory methods relying on Java reflection classes and transform them into extension functions on companions. The "jvm" package is temporary, there'll be a new module in future.