Skip to content

generate extensions of wrapper types owned by other modules - #852

Open
Tatenda-k wants to merge 2 commits into
swiftlang:mainfrom
Tatenda-k:main
Open

generate extensions of wrapper types owned by other modules#852
Tatenda-k wants to merge 2 commits into
swiftlang:mainfrom
Tatenda-k:main

Conversation

@Tatenda-k

Copy link
Copy Markdown

##What
Teaches wrap-java to generate a Swift extension of a wrapper type that is defined in a different Swift module, containing only the members whose signatures or return type references at least one type wrapped by the module being generated.
Opt in per-module via a new manifest field:
"extendForeginclasses": ["java.lang.Class"]

Scope/Follow-up

This PR adds the capability + tests. It does not yet delete the hand-written
JavaClass+Reflection.swift: the wrap-java tool itself calls several of those
JavaClass methods, so the generated JavaClass+Extensions.swift must be
produced and committed (a one-time bootstrap) before the hand-written file can be
trimmed. Tracked as follow-up.
addresses #18

@Tatenda-k
Tatenda-k requested a review from ktoso as a code owner July 27, 2026 17:11
// methods (e.g. `getDeclaredMethod`, `getFields`, `getGenericSuperclass`) to do
// its work, so the generated `JavaClass+Extensions.swift` must first be produced
// and committed (a one-time bootstrap) before the hand-written members here can
// be removed.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't keep such LLM-ish comments that serve as roadmaps or todolists, we should do this in the same commit rather I think

let importDecls = translator.getImportDecls()

let swiftFileText = """
// Auto-generated by Java-to-Swift wrapper generator.

@ktoso ktoso Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not really a term we use; the tool is swift-java wrap-java or just wrap-java here.

/// Fully-qualified Java class names whose Swift wrapper type is defined in a
/// *different* Swift module (a dependency), but which should gain extra members
/// generated by the module this configuration belongs to (`swiftModule`).
public var extendForeignClasses: [String]? = nil

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have a typealias for these, we could use JavaFullyQualifiedTypeName here

@ktoso ktoso left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm supportive of the fix but it's pretty messy and very LLM-ish, would you mind refactoring it a bit please so it's more structured?

Also, the "follow up" should be done immediately in the same PR I think

// module (`effectiveSwiftModule`) — is implemented in
// `JavaClassTranslator.renderForeignExtension`.

for foreignClassName in config.extendForeignClasses ?? [] {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this should be put into a new method I think, there it can have the comment; please write the comment youtrself, this sounds very LLM-ish and is a bit hard to understand tbh.


/// Render an `extension <Wrapper> { ... }` adding members that reference at
/// least one type owned by the current module.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stray newline, please remove

Suggested change

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.

2 participants