There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a proposal needs to be made) does not seem very necessary. Is there a b

[fliter]

There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a proposal needs to be made) does not seem very necessary. Is there a better solution?

[Jason Phillips]

If you're trying to share code among related packages within a module but not external to the module, "internal" packages[1][2] are one common way to accomplish that. It's a convention that's enforced by the "go" command. This solution is used within the standard library and other official packages[3].

If that doesn't help you, would you mind explaining a bit more what you're trying to do? An example would be useful.

1 - https://go.dev/doc/go1.4#internalpackages

2 - https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface

3 - https://github.com/golang/go/tree/master/src/internal

[Ian Lance Taylor]

On Tue, Apr 4, 2023 at 12:05 PM fliter <imc...@gmail.com> wrote:
>
> There are many private methods with identical code in several different packages, which is clearly not elegant; But adding a public method that can be accessed by other packages (a proposal needs to be made) does not seem very necessary. Is there a better solution?

Since you mention a proposal, I assume that you are talking about the
standard library. It's possible to coalesce identical functions into
an internal package. An internal package is not publicly visible and
as such does not require a proposal.

Ian

[fliter]

Thanks

[fliter]

Thanks