Skip to content

Split generated code into multiple files #1796

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

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

Conversation

kgominyuk
Copy link

Code generation can significantly bloat the app size in large projects. Splitting generated code into multiple files allows teams to decide which features they want to include in their code.

Before

my.proto
  ↓
my.pb.swift

After

my.proto
  ↓
my.pb.swift
my.pb.hashable.swift
my.pb.nameproviding.swift

contents: filePrinter.main.content
)
try generatorOutputs.add(
fileName: fileGenerator.outputFilename(".pb.hashable.swift"),
Copy link
Collaborator

Choose a reason for hiding this comment

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

In the SwiftProtobuf sources, we have the convention that a file declaring an extension of some type gets named "Type+Protocol.swift"

I wonder if some variant of that convention would be more appropriate here? I think that would end up giving us ".pb+Hashable.swift" which is admittedly a little weird looking. But at a minimum, Hashable and NameProviding in these filenames should be correctly capitalized.

Copy link
Author

Choose a reason for hiding this comment

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

my.pb+Hashable.swift
my.pb+NameProviding.swift

or

my+Hashable.pb.swift
my+NameProviding.pb.swift

?

@thomasvl
Copy link
Collaborator

Since some of these seems like they will only have protocol additions, do we run the risk of exposing problems like #1061 again?

With #18 and #1240, one of the concerns can be how do things then present to developers. If the runtime still exposes the TextFormat and JSON methods of all messages, then someone not linking the right files will still build, and they would get a odd runtime failure. And it isn't just for the root message type, it would be an error from any of the transitive message types. So moving these to extensions means code can compile and fail at runtime which is sorta counter what I'd normally expect for a lot of Swift. It seems like it would be better if there was an way to ensure a developer couldn't try to call the methods if the support is going to be missing (atleast for the topmost message).

@kgominyuk
Copy link
Author

So moving these to extensions means code can compile and fail at runtime which is sorta counter what I'd normally expect for a lot of Swift.

What do you think about these things:

  1. Moving func jsonString() into extension Message where Self: _ProtoNameProviding
  2. Add something to the _ProtoNameProviding generated code that checks at compile time that all message properties conform _ProtoNameProviding. For example:
  private var _protobuf_ProtoNameProviding_conformance: [SwiftProtobuf._ProtoNameProviding] {
    return [
      _property1,
      _property2,
    ]
  }

In theory it should not affect binary size, since this variable won't be used anywhere.

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.

3 participants