jet icon indicating copy to clipboard operation
jet copied to clipboard

feature: export functions and remove internal package

Open switchupcb opened this issue 1 year ago • 5 comments

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:

  1. Use of internal: Using jet programmatically with an interpreter requires you to use functions which reference internal, when functions in an internal package cannot be referenced. So, the developer must rename the entire internal package to use jet with an interpreter.
  2. Unexported functions
    1. genTemplate is unexported which requires the developer to inline a definition or export the function to use jet programmatically.
    2. postgres package contains unexported functions which requires the developer to export them when using jet with 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

switchupcb avatar Mar 11 '25 16:03 switchupcb

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.

go-jet avatar Mar 13 '25 12:03 go-jet

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?

  1. genTemplate functions for MySQL, SQLITE, and Postgres to call Generate
  2. functions in import "github.com/go-jet/jet/v2/postgres" (example commits provided)

— @switchupcb

switchupcb avatar Mar 17 '25 02:03 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.

go-jet avatar Mar 23 '25 16:03 go-jet

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

switchupcb avatar Mar 24 '25 14:03 switchupcb

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

switchupcb avatar Mar 24 '25 14:03 switchupcb