я только о том, что `findViewById`это уже делает

ну в общем получается то, что сделано в kotterknife

только вместо findViewById - bindView

хотелось уйти от bindBiew

либо заменив на одиночный символ, либо еще как-то

ну, еще есть вариант с аннотациями с каким-нибудь даггером, но как пом не так bindView не большая цена за удобство

можно накрайняк написать

fun i() = bindView()

и наслаждаться

fun <V : View> View.i(id: Int) = bindView<V>(id)

i некрасиво))

вот на джаве можно метод назвать $

четко

мм, где-то я уже такое видел

?

private val btn: Button by findViewById(R.id.btn)

минус такого подхода в том, что на каждую вью создастся объект Lazy

а если у меня 20 вью

20 лишних объектов-контейнеров, как с куста?

А kotlin synthetic extensions чем не подходят?

Никаких объявлений, лучше любого KotterKnife

И всего рукописного

мб

надо плотно попробовать

Ты просто обращаешься к вьюхе по id и все, магия

я в курсе

Ни объявлений переменных

мне не нравится наблюдать в коде такие же имена, как и в xml

ну хотя в этом есть и преимущество

мне не нравится наблюдать в коде такие же имена, как и в xml

так называй не btn_ok, a btnOk например

так называй не btn_ok, a btnOk например

в существующем проекте долго переименовывать

в существующем проекте долго переименовывать

для существующего просто смирись )

кстати

а для джавы есть такая штука?

ток не датабиндинг))

чтоб тоже просто искала вьюхи с айди и они были доступны в коде

вообще непонятно почему такое не сделали по умолчанию)

Там иначе принимают решение, все думают об обратной совместимости

Да и не все в xml выносят все

В iOS на Свифте перетаскиваешь мишкой и биндиш)

В iOS на Свифте перетаскиваешь мишкой и биндиш)

То совсем другая история

Тут был вопрос про книжку на русском, так вот она будет и видимо достаточно скоро, но переводить ее будут не авторы, пока сильно больше подробностей нет

Котлин используют по выходным, груви нет, такие дела http://www.opennet.ru/opennews/art.shtml?num=46033

Потому что с Груви работу работают а не по выходным балуются

Серьезный язык, для серьезной разработки, что уж тут

Scala когда то тоже больше на выходных баловались

Как раз таки нет, там тендеция другая

как же нет. 10 лет назад так и было

или думаешь первые энтузиасты сразу в прод скалу потащили? :)

На то они и энтузиасты!

Проблема только в том что JB пытается создать язык который будут юзать по будням (но пока не получается).

А что, собственно, не получается? Я пишу на Kotlin по будням. ;)

вполне годный язык. уже пару сервисов в прод на нем запустил

А что, собственно, не получается? Я пишу на Kotlin по будням. ;)

Пиши больше, что бы стату набить ? (я тоже пишу только на нем). В JB пилят его как C# для JVM и видимо рассчитывают на тоже место, а не как между Clojure и F#.

кстати а как считали эту стату?

Пиши больше, что бы стату набить ? (я тоже пишу только на нем). В JB пилят его как C# для JVM и видимо рассчитывают на тоже место, а не как между Clojure и F#.

Мне вообще безразлична твоя «стата». Я спрашиваю, что у них не получается.

Мне вообще безразлична твоя «стата». Я спрашиваю, что у них не получается.

Сделать что-то больше чем C# 2010 (все-таки за C# тоже тянется свое легаси).

чего конкретно не хватает?

Ну просто возьми и сравни его со Scala

Восхитительная беседа.

а конкретнее чего именно не хватает без чего невозможно жить?

паттерн матчинга?

тайп алиасов?

Взять те же макросы их вроде уже и в groovy завозят.

и как идея их поддерживает, нормально?

С их задачей отлично справляются инлайновые функции.

тайп алиасов?

тайп алиасы уже же анонсировали

С их задачей отлично справляются инлайновые функции.

Хех >> What Scala has that Kotlin does not ... Macros https://kotlinlang.org/docs/reference/comparison-to-scala.html

тайп алиасы уже же анонсировали

да скоро ж 1.1 релиз, заценим их)

тайп алиасы уже же анонсировали

да и запилили уже

Хех >> What Scala has that Kotlin does not ... Macros https://kotlinlang.org/docs/reference/comparison-to-scala.html

Никто не говорил, что они есть в Котлине. Их нет, но большая часть задач, возлагаемых на них, решаема инлайновыми функциями.

Как говорил Бреслав, если делать язык, в котором всё есть, получится ALGOL-68.

...или скала

ну а если ничего не делать, получится go

`inline`-функции с многими кейзами макросов справляются, а для сложных решений есть кодогенерация, кстати, вполне юзабельная (kapt)

Как говорил Бреслав, если делать язык, в котором всё есть, получится ALGOL-68.

Давай те просто согласимся что Kotlin = Java с сахаром. Как говорил тот же Бреслав, это язык который смогут понять большинство Java программистов.

javascript -- это ассемблер с очень большим количество сахара

`inline`-функции с многими кейзами макросов справляются, а для сложных решений есть кодогенерация, кстати, вполне юзабельная (kapt)

Ну да и в Java есть кодо-генерация ?

Ну да и в Java есть кодо-генерация ?

дык это она и есть

Давай те просто согласимся что Kotlin = Java с сахаром. Как говорил тот же Бреслав, это язык который смогут понять большинство Java программистов.

Давайте просто согласимся, что ни один язык не равен другому, даже с сахаром. Груви тоже может понять большинство Java-программистов. Шарп могут понять большинство С++-ников. И так далее.

OK - согласен, звучит разумно

котлин всё-таки пытается завоевать репутацию вполне независимого от java языка, более того, даже от jvm независимого, судя по компиляции в js и kotin-native

Давай те просто согласимся что Kotlin = Java с сахаром. Как говорил тот же Бреслав, это язык который смогут понять большинство Java программистов.

Как будто это что то плохое

Кстати. Никому не приходило в голову, что разработчики котлина плотно сидели на книжке effective java?

а кто не сидел?

все сидят

final классы да?

Не только

Давай те просто согласимся что Kotlin = Java с сахаром. Как говорил тот же Бреслав, это язык который смогут понять большинство Java программистов.

сахар это когда есть 2 способа сделать что-то

Кстати. Никому не приходило в голову, что разработчики котлина плотно сидели на книжке effective java?

так разрабы этого и не отрицают, что взяли многое из книги

О чём разговор вообще?

так разрабы этого и не отрицают, что взяли многое из книги

Не знал

Не знал

https://medium.com/@lukleDev/how-effective-java-may-have-influenced-the-design-of-kotlin-part-1-45fd64c2f974#.5bbgcfwjb https://medium.com/@lukleDev/how-effective-java-may-have-influenced-the-design-of-kotlin-part-2-89844d62ddf3#.ezv4xwpv8 вот даже статейки есть