Move Java reflect specific extensions into a separate package #299
Conversation
| @@ -15,6 +15,7 @@ | |||
| */ | |||
| package com.squareup.kotlinpoet | |||
|
|
|||
| import com.squareup.kotlinpoet.jvm.asClassName | |||
There was a problem hiding this comment.
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.
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.
How about @JvmMultifileClass and the same @JvmName?
There was a problem hiding this comment.
I doubt it'll work across multiple modules, but I can give it a try
There was a problem hiding this comment.
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.
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.
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.
Should all of these just be a single class, JvmTypeNames ?
There was a problem hiding this comment.
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.