-
Notifications
You must be signed in to change notification settings - Fork 108
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
Finish support for "import public" #19
Comments
blackgnezdo
pushed a commit
that referenced
this issue
Aug 17, 2018
The comment did say that only flat shapes were supported though.
judah
added a commit
that referenced
this issue
Aug 27, 2019
Fixes #19. After this change, if `bar.proto` contain the line import public foo.proto Then it turns into ``` module Proto.Bar(..., module Proto.Foo) where import qualified Proto.Foo import Proto.Foo -- unqualified, to allow the reexport of its definitions ``` The redundant `qualified` import is to make the codegen simpler, and should be harmless. The previous hacky approach was: `Proto.Bar` doesn't reexport `Proto.Foo`; instead, if `baz.proto` imports `bar.proto`, *then* the codegen of `Proto.Baz` imports `Proto.Foo` as well as `Proto.Bar`. This had two limitations: 1) It violated the principle of "strict dependencies", since `Proto.Baz` is importing what is essentially a transitive dependency. 2) Non-codegen modules that import a proto module can't benefit from `import public` statements.
judah
added a commit
that referenced
this issue
Aug 27, 2019
Fixes #19. After this change, if `bar.proto` contains the line import public foo.proto Then it turns into ``` module Proto.Bar(..., module Proto.Foo) where import qualified Proto.Foo import Proto.Foo -- unqualified, to allow the reexport of its definitions ``` The redundant `qualified` import is to make the codegen simpler, and should be harmless. The previous hacky approach was: `Proto.Bar` doesn't reexport `Proto.Foo`; instead, if another file `baz.proto` imports `bar.proto`, *then* the codegen of `Proto.Baz` imports `Proto.Foo` as well as `Proto.Bar`. This approach let us avoid module-level exports, but had two limitations: 1) It violated the principle of "strict dependencies", since `Proto.Baz` is importing what is essentially a transitive dependency. 2) Non-codegen modules that import a proto module can't benefit from `import public` statements.
judah
added a commit
that referenced
this issue
Aug 27, 2019
Fixes #19. After this change, if `bar.proto` contains the line import public foo.proto Then it turns into ``` module Proto.Bar(..., module Proto.Foo) where import Proto.Foo -- unqualified, to allow the reexport of its definitions ``` The previous hacky approach was: `Proto.Bar` doesn't reexport `Proto.Foo`; instead, if another file `baz.proto` imports `bar.proto`, *then* the codegen of `Proto.Baz` imports `Proto.Foo` as well as `Proto.Bar`. This approach let us avoid module-level exports, but had two limitations: 1) It violated the principle of "strict dependencies", since `Proto.Baz` is importing what is essentially a transitive dependency. 2) Non-codegen modules that import a proto module can't benefit from `import public` statements.
judah
added a commit
that referenced
this issue
Aug 28, 2019
Fixes #19. After this change, if `bar.proto` contains the line import public foo.proto Then it turns into ``` module Proto.Bar(..., module Proto.Foo) where import Proto.Foo -- unqualified, to allow the reexport of its definitions ``` The previous hacky approach was: `Proto.Bar` doesn't reexport `Proto.Foo`; instead, if another file `baz.proto` imports `bar.proto`, *then* the codegen of `Proto.Baz` imports `Proto.Foo` as well as `Proto.Bar`. This approach let us avoid module-level exports, but had two limitations: 1) It violated the principle of "strict dependencies", since `Proto.Baz` is importing what is essentially a transitive dependency. 2) Non-codegen modules that import a proto module can't benefit from `import public` statements.
avdv
pushed a commit
to avdv/proto-lens
that referenced
this issue
Aug 9, 2023
Fixes google#19. After this change, if `bar.proto` contains the line import public foo.proto Then it turns into ``` module Proto.Bar(..., module Proto.Foo) where import Proto.Foo -- unqualified, to allow the reexport of its definitions ``` The previous hacky approach was: `Proto.Bar` doesn't reexport `Proto.Foo`; instead, if another file `baz.proto` imports `bar.proto`, *then* the codegen of `Proto.Baz` imports `Proto.Foo` as well as `Proto.Bar`. This approach let us avoid module-level exports, but had two limitations: 1) It violated the principle of "strict dependencies", since `Proto.Baz` is importing what is essentially a transitive dependency. 2) Non-codegen modules that import a proto module can't benefit from `import public` statements.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
.proto files with "import public" statements don't re-export the public imports.
For example, if
foo.proto
containsThen the generated module
Foo.hs
should re-export all the names defined inBar.hs
.I think this is doable, but it might be a little tricky to avoid name conflicts between the autogenerated field accessors in
Foo.hs
andBar.hs
.The text was updated successfully, but these errors were encountered: