Да и к тому же, зачем вам вот прямо immutable объе...

# russian

[elizarov]

Да и к тому же, зачем вам вот прямо immutable объет? Ну заведите к нему read-only интерфейс (как в коллекциях). Это тоже, конечно, boilerplate, но существенно меньший чем builders. Этот boilerplate мы может когда-нибудь поборим прямо в языке в рамках работы над immutablity

[snrostov]

В качестве самого простого решения, можно было бы позволить конструкцую такого вида out User, которая, так же как и в дженериках просто бы запрешала использовать "in" методы.

Например:

class User(var name: String)

val mutableUser = User("name")
mutableUser.name = "name1" // ok

val user = out User("name")
user.name = "name1" // ok

По аналогии с тем что работает уже сейчас

class User<S>(var name: S)

val mutableUser = User("name")
mutableUser.name = "name1" // ok

val user: User<out String> = User("name")
user.name = "name1" // error

хотя, конечно, выглядит совсем не очевидно. если только не заменить "out" на "const" 🙂

[snrostov]

Ну и конечно же тут речь только о "read-only" типе, который не совсем "const"

[elizarov]

Это все тлетворное влияние C++. Не надо так делать. Mutable это не правильный дефолт в 21-с веке. Должно быть наоборот. Как List. То есть immutable by default. А если хочешь менять, то явно проси Mutable.

[snrostov]

А, ну да. Теперь я понял что в вашем примере значит "mut". Immutable по умолчанию конечно же лучше