Как комментировать символы, которыми они делятся между другими проектами? - PullRequest
2 голосов
/ 19 февраля 2020

Предположим, у меня есть проект Go, который действует как общая библиотека в другом проекте Go. Как мне пометить Go символы (константы, структуры, переменные), чтобы они использовались вне этого проекта?

Я предполагаю, что основная проблема заключается в том, что мне трудно узнать, какой код использует указанные символы.

Обратите внимание: это не о семанти c версиях , о которых мне очень хорошо известно и которые я использую. Я знаю, что Semver может помочь в выявлении критических изменений.

Вместо этого речь идет о том, чтобы выяснить, действительно ли я нарушаю один из моих собственных проектов (по сравнению с: этот символ должен быть не экспортирован или использован вне пакета). Я имею в виду какую-то аннотацию, которой нет в Go.

Кроме того, IntelliJ не знает ни того, ни другого и помечает эти символы как «Излишне экспортированные». Возможно, решения IntelliJ-centri c может быть достаточно.

Чтобы проиллюстрировать мою проблему:

package sharedlib

import "time"

// MyFavoriteTimeFormat is a blablabla...
const MyFavoriteTimeFormat = Time.RFC3339
package dependingproject

import "github.com/thething/sharedlib"
import "time"

func convertToString(timestamp time.Time) string {
    return timestamp.Format(sharedlib.MyFavoriteTimeFormat)
}

Когда я с радостью переименую MyFavoriteTimeFormate и отпущу его, код сломается в зависимом проекте при обновлении зависимости.

1 Ответ

2 голосов
/ 19 февраля 2020

Не экспортируйте ничего, пока это не понадобится другому пакету. Если другому пакету что-то нужно, тогда выполните экспорт, и тогда вы узнаете, что если что-то экспортируется, то это потому, что оно используется вне пакета. И не делайте критических изменений на экспортируемых идентификаторах. Если вам действительно нужно, то увеличьте основную версию. Используя go модули, которые не сломают существующие другие пакеты, они будут продолжать использовать старую версию.

Если ваш модуль разбит на несколько пакетов (потому что он «большой»), и вы wi sh чтобы экспортировать что-то исключительно для других пакетов вашего модуля, затем использовать концепцию внутреннего пакета, так что это все еще будет «не экспортировано» (не импортируемо) в другие модули. Подробнее см. Можно ли разработать пакет go в нескольких исходных каталогах?

...