feature: export functions and remove internal package
How can you increase the library's usage and contributions?
Problem
You are limiting the library's usage and contributions by using an internal package and unexported functions.
dbgo uses a modified version of jet to interpret a Go file and output type-safe SQL.
Here are the issues experienced while implementing this functionality:
- Use of
internal: Usingjetprogrammatically with an interpreter requires you to use functions which referenceinternal, when functions in aninternalpackage cannot be referenced. So, the developer must rename the entireinternalpackage to usejetwith an interpreter. - Unexported functions
-
genTemplateis unexported which requires the developer to inline a definition or export the function to usejetprogrammatically. -
postgrespackage contains unexported functions which requires the developer to export them when usingjetwith an interpreter.
-
Implementation
You can increase the library's usage and contributions by replacing the internal package and exporting certain unexported functions.
https://github.com/switchupcb/jet/tree/dbgo is a version of jet which has these problems fixed for PostgreSQL functionality.
Implementation: Internal Usage
The solution to this problem requires further discussion among maintainers.
Implementation: Export Unexported Functions
You can approve the decision to export unexported fuinctions required for usage of jet in an interpreter (e.g., functions in import "github.com/go-jet/jet/v2/postgres") and I can create a pull request to solve this problem.
Here are example commits:
- https://github.com/switchupcb/jet/commit/1ba2f4d55dacc2eb5513f0d40485531ee03e23c4
- https://github.com/switchupcb/jet/commit/26ee4c529d640ec60255d10c61387277b8749684
If everything is exported, then everything becomes part of the public API, which limits maintainability. For instance if we need to refactor something which is often the case, we might break someones build.
There might be cases where certain elements aren't exported and they should, but these will be evaluated individually.
Making everything public is out of question.
There might be cases where certain elements aren't exported and they should, but these will be evaluated individually. — @go-jet
What is the evaluation of the exporting the unexported functions listed in the original issue?
genTemplatefunctions for MySQL, SQLITE, and Postgres to callGenerate- functions in import "github.com/go-jet/jet/v2/postgres" (example commits provided)
— @switchupcb
genTemplate functions for MySQL, SQLITE, and Postgres to call Generate
genTemplate in ./cmd/jet/main.go ?
functions in import "github.com/go-jet/jet/v2/postgres" (example commits provided)
windowExpand - is not an expression, just start of building an expression, so it doesn't make sense to export it.
genTemplate in ./cmd/jet/main.go ? — @go-jet
You cannot call Generate from programmatic usage of jet without defining a template.Template.
https://github.com/go-jet/jet/blob/fb7c376ba512ccac9e9346245c38c20407c91842/generator/postgres/postgres_generator.go#L40
There is no documentation explaining how to define a template other than genTemplate, which is returned as a parameter from an exported function GenerateDSN.
https://github.com/go-jet/jet/blob/fb7c376ba512ccac9e9346245c38c20407c91842/cmd/jet/main.go#L242
Here is how jet defines a template using the unexported function.
https://github.com/go-jet/jet/blob/fb7c376ba512ccac9e9346245c38c20407c91842/cmd/jet/main.go#L101
windowExpand - is not an expression, just start of building an expression, so it doesn't make sense to export it. — @go-jet
When does exporting a struct required to implement an exported interface make sense?
Nothing can implement a jet.SelectStatement interface because windowExpand is returned from a function referenced by the exported SelectStatement interface.
- The same logic applies to
fetchExpand.
https://github.com/go-jet/jet/blob/fb7c376ba512ccac9e9346245c38c20407c91842/postgres/select_statement.go#L42