https://kotlinlang.org logo
Title
e

elizarov

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

snrostov

10/06/2017, 9:30 PM
В качестве самого простого решения, можно было бы позволить конструкцую такого вида
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" 🙂
Ну и конечно же тут речь только о "read-only" типе, который не совсем "const"
e

elizarov

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

snrostov

10/06/2017, 9:37 PM
А, ну да. Теперь я понял что в вашем примере значит "mut". Immutable по умолчанию конечно же лучше