A modern programming language that makes developers happier.

kotlinlang

Всем привет!
Всего лишь уточнить....
*package-private* нам стоит ожидать хотя бы в ближайшем обозримом будущем? Или уже окончательно распрощаться с этой идеей?
Сейчас планируем архитектуру и хотелось бы принять заведомо правильное и долгосрочное решение.
Спасибо.

Финального решения не ожидается в ближайшем будущем (как минимум до 2.2 точно)

Понял. Большое спасибо!

А зачем нужен, этот *package-private*? Он же “взламывается” из другого модуля. Чем *internal* не подходит?
Я для своего развития, если что :slightly_smiling_face:

Есть проблема, когда есть несколько модулей в рамках одной библиотеки, и хочется что-то шарить только между этими модулями, не отдавая наружу
И `internal`, и `package-private` не решают этой проблемы

Кстати, классное замечание.
У меня аргументы проще, но не менее болезненее:
интернал -влечёт высоко гранулярную помодульность.
И часто это бывает избыточно и неудобно

Создать модуль != создать пакет.
Да и технически модуль != пакет.
Over-модульной суеты - когнитивно сильно больше, чем с пакетами

Однако если создание модуля достигнет такой же простоты как и пакета....и будет автоматизировано или скрыто от разработчика - то и не особо этот package private нужен

<@UKPEELJCW> я и сам использовал, и в других библиотеках видел,  что такую вещь обычно делают через экспериментальные аннотации вида `@InternalSomeLibraryApi`

Да, это один из workaround'ов
Другой -- это `internal` + `@Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE")`
Из-за их наличия эта проблема не в большом приоритете

Ну это жесть… Хотя авторы либ и не такое делают...

хотя... межпакетно инкапсулировать - это вряд ли поможет

Если что, вариант с `Suppress` -- это не рекомендация
Никогда не надо саппресить ошибки

Скажи это `UNCHECKED_CAST`, заткнутому на каждом углу.