Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Egorand
Copy link
Collaborator

@Egorand Egorand commented Dec 14, 2017

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.

@@ -15,6 +15,7 @@
*/
package com.squareup.kotlinpoet

import com.squareup.kotlinpoet.jvm.asClassName
Copy link
Collaborator Author

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")
Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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")
Copy link
Collaborator

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 ?

Copy link
Collaborator

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?)

Copy link
Collaborator Author

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!

@swankjesse
Copy link
Collaborator

@Egorand status on this?

@Egorand
Copy link
Collaborator Author

Egorand commented Jul 25, 2018

I wanna do #304 (multiplatform project), based on the learnings from Okio. Will keep this around for some time and then close.

@micHar
Copy link

micHar commented Jan 9, 2021

Is this abandoned? Is there any way to use kotlinpoet to generate kotlin used by multiplatform modules?

@JakeWharton
Copy link
Collaborator

That has always been possible. This ticket is for running KotlinPoet itself in non-JVM contexts.

@Egorand Egorand changed the base branch from master to main July 5, 2023 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants