SS
да, из питерского офиса видимо
Size: a a a
2021 January 21
AP
я вот с недавнего времени стал отчетливо замечать эту пропасть в коммуникации
AP
и в резюме
D
когда к нам в Стокгольм приезжала девушка из джетбрейнс на митап рекламировать котлин, первый вопрос от бородатых джавистов был а че у вас там с дефолтной видимостью так вышло. Девушка ответила что-то типа не хотите, не пишите, и джависты в перерыв дружно свалили 😀
А они effective java читали? :)
SS
А они effective java читали? :)
джависты или джетбрейнисты? 😀
D
джависты или джетбрейнисты? 😀
Джависты
SS
ну я читал, что ты имеешь в виду. там вроде было написано делать визибилити минимальной
D
Это ж первопричина некоторых языковых решений
SS
стопудово новые программисты на котлине и свифте не читали никаких эффектив че-то там и все понапишут в паблик </troll>
D
My bad. Публичная видимость связана с избавлением от излишней церемониальности.
http://blog.jetbrains.com/kotlin/2015/09/kotlin-m13-is-out
http://blog.jetbrains.com/kotlin/2015/09/kotlin-m13-is-out
D
стопудово новые программисты на котлине и свифте не читали никаких эффектив че-то там и все понапишут в паблик </troll>
Недавно завезли strict режим для разработчиков библиотек. Можно настроить чтобы компилятор орал, если не указано явно.
SS
да, я читал это
SS
This may seem controversial that we chose public as default visibility. Kotlin being a type-safe language, choosing the safest option, private, by default may seem more logical. And we totally realize there are valid arguments in favour of this default. But Kotlin is also a pragmatic language. I’ll try to explain briefly why we believe public is the right default.
In real Java code bases (where public/private decisions are taken explicitly), public occurs a lot more often than private (2.5 to 5 times more often in the code bases that we examined, including Kotlin compiler and IntelliJ IDEA). This means that we’d make people write public all over the place to implement their designs, that would make Kotlin a lot more ceremonial, and we’d lose some of the precious ground won from Java in terms of brevity. In our experience explicit public breaks the flow of many DSLs and very often — of primary constructors. So we decided to use it by default to keep our code clean.
In real Java code bases (where public/private decisions are taken explicitly), public occurs a lot more often than private (2.5 to 5 times more often in the code bases that we examined, including Kotlin compiler and IntelliJ IDEA). This means that we’d make people write public all over the place to implement their designs, that would make Kotlin a lot more ceremonial, and we’d lose some of the precious ground won from Java in terms of brevity. In our experience explicit public breaks the flow of many DSLs and very often — of primary constructors. So we decided to use it by default to keep our code clean.
AP
“explicit public breaks the flow of many DSLs and very often — of primary constructors” вот тут бы пример неплохо бы смотрелся
D
“explicit public breaks the flow of many DSLs and very often — of primary constructors” вот тут бы пример неплохо бы смотрелся
Праймари конструктор в Котлине совмещен с декларацией класса
AP
Праймари конструктор в Котлине совмещен с декларацией класса
ааа
D
class Foo(val bar: String) {}
AP
This may seem controversial that we chose public as default visibility. Kotlin being a type-safe language, choosing the safest option, private, by default may seem more logical. And we totally realize there are valid arguments in favour of this default. But Kotlin is also a pragmatic language. I’ll try to explain briefly why we believe public is the right default.
In real Java code bases (where public/private decisions are taken explicitly), public occurs a lot more often than private (2.5 to 5 times more often in the code bases that we examined, including Kotlin compiler and IntelliJ IDEA). This means that we’d make people write public all over the place to implement their designs, that would make Kotlin a lot more ceremonial, and we’d lose some of the precious ground won from Java in terms of brevity. In our experience explicit public breaks the flow of many DSLs and very often — of primary constructors. So we decided to use it by default to keep our code clean.
In real Java code bases (where public/private decisions are taken explicitly), public occurs a lot more often than private (2.5 to 5 times more often in the code bases that we examined, including Kotlin compiler and IntelliJ IDEA). This means that we’d make people write public all over the place to implement their designs, that would make Kotlin a lot more ceremonial, and we’d lose some of the precious ground won from Java in terms of brevity. In our experience explicit public breaks the flow of many DSLs and very often — of primary constructors. So we decided to use it by default to keep our code clean.
то есть грубо та же причина что и у моего разрабочтика, писать много))
D
то есть грубо та же причина что и у моего разрабочтика, писать много))
Но пакеты то есть! 😁
D
И тернарника нет и не будет. А это - писать длиннее.