Я знаю несколько способов обойти описанную проблему, к описанному выше еще можно добавить "?.let", но вопрос был не об этом.
Есть ли какие-то подтверждения того, что запрет на smart cast растет именно из "потенциальной неодинаковости getter-а", а не из-за многопоточности?
Этот пример говорит об обратном:
class A {
private var value : Int? = 0
fun F() : Int {
if ( value == null ) return 0
return value
}
}
Ошибка точно та же, гетеров нет. То же и с "@JvmField".
Да, скорее всего, будут что-то менять.
Я лично на это даже надеюсь :)
Пока я каких-то проблем не испытывал.
Вот сегодня (вчера) прилетела обнова языка и в ней оказались ампутированными битовые операции для типов Short и Byte. Пришлось править кусок либы и я уже хотел по этому поводу расстроиться, но потом посмотрел на реализацию и на Java и, в общем-то, причина этого действия стала ясна. Меня "убедили" в адекватности этого действия.
Пока это было максимальное, на что я нарывался.
Да и, на мой взгляд, движуха в языке не является особой проблемой.
В любой развивающейся системе будут изменения — этого не избежать.
Я лично пришел к следующему рецепту: при обновлении смотрю на ньюсы и, если количество решенных проблем или интересных фич перевешивает трудозатраты на адаптацию, то перехожу; если нет — сижу на старой версии.
Это я по опыту изменений, которые приходилось вносить с принципиальным перелопачиванием многих сотен кб сорсов. В Kotlin-же я пока не видел ничего даже отданно схожего по трудозатратам.
Я лично выбрал этот язык с прицелом именно на андроид т.к. остальные альтернативы мне показались значительно хуже либо синтаксически и стилистически (например Scala), или принципиально (например, нетипизированный Groovy).
На мой взгляд, именно Kotlin максимально близок к Swift, но, возможно Вам лучше подойдет что-то другое т.к. иногда лучше перейти на что-то совсем другое, чем "очень похожее, но совсем не такое в мелочах" — будет меньше ошибок и расстройств.
Меня просто поржает: с чего такая агрессивность-то?
Наследие "кг\ам" или просто день не задался?
Если я чем умудрился обидеть, то прошу прощения.
В комменте, практически в каждом пункте текст, который вызван простым непониманием вопроса в статье.
Не проблема, я не заставляю этот текст читать, тем более что, видимо, это противно.
Это взаимно, так что на этом прощаюсь
За пару часов язык в принципе освоить невозможно и, соответственно, делать о нем какие-то выводы сложно.
Свифт, наверное, хорош (когда возникла необходимость писать под иос я, взглянув на синтаксис objective-C сказал что буду это делать только за очень отдельные деньги, и вопрос с тех пор не поднимался, жаль тогда не было свифта) но, к сожалению, за пределами одной платформы его не существует.
Если же возникает задача для андроида, то, на мой взгляд, Kotlin — это наилучший выбор.
Уж в сравнении с явой-то точно.
Кратенько, по существу т.к. придирки и упражнения с схоластике не особо интересны.
У for-in своя семантика, это не for из C.
То что сейчас в Kotlin — это foreach, который именно в таком виде завели в каком-нить С# именно для того, чтобы обозначить его нишу.
Мне, по сути, без разницы как оно называется.
У меня претензия к отсутствию альтернативы нормального for. Считайте его хоть из С хоть из Java.
Нет, чистый Kotlin null-safe, проверки будут только на стыке Java и Kotlin.
Это неправда.
Посмотрите генерируемый код.
А на стыке Java\Kotlin как раз проверок не будет вообще, если на стороне Kotlin явно не указан "?"-й тип.
Потому что в Java все потоки работают с одной кучей и в общем случае объект не привязан к какому-то отдельному потоку.
В Java не нужно обеспечивать синхронизацию? Все операции\функции\блоки… атомарны? Компилятор как-то автоматически за меня определит границы блока синхронизации и создаст для них код?
Если нет, то аргумент не принимается.
ПС: Я не знаю языков где "объект привязан к какому-то потоку". Такие существуют?
Наоборот.
Специально для внешнего кода убрали проверки.
Находил описание, когда наступил на эти грабли в каком-то парсере и начал искать почему в коде нет проверок.
Полное содержимое кейса я не помню, но смысл был в том, что при наличии проверок ломался какой-то код.
Сейчас нулабле-тип объявленный в Kotlin имеет тип "?", а из Java "!".
//KOTLIN:
fun sNULL() : String? = ""
//JAVA:
public static String F1() { return null; }
val k = sNULL() // тип переменной String?
val j = jTest.F1() // тип переменной String!
Для первого проверки производятся, и выдаются все предупреждения, а для второго нет.
Действительно, в нем декларируется "Ceylon's type system is fully reified at runtime" и в качестве примера приводят именно "if (is Map<String,Object> map)".
Интересно, какой ценой они этого добились?
Усложняет, разумеется, не наличие бесполезного цикла, а отсутствие полезного.
Фор — это очень удобная и краткая конструкция с двумя выражениями и одним условием.
Она короткая и очень наглядная.
Для меня лично, разворачивание его в while с отдельным описанием переменных, значительно снижает читаемость кода.
Мне совершенно не нужно, чтобы это поле было доступно конечному юзеру.
class A {
@PublishedApi
internal val allow = false
inline fun F(cb : () -> String) {
if (allow) println(cb())
}
}
fun main(a : Array<String>) {
val a = A()
println( a.allow ) //Мне НЕ надо чтобы был доступ
}
Если бы я захотел сделать поле доступным, то я бы это сделал просто указав public, зачем вообще эта аннотация нужна?
Можете привести пример ее осмысленного использования?
Да, извиняюсь, не сообразил с доступом.
Тем не менее (и даже более), выдавать сообщения основанные на внутренних собенностях реализации, о которых никто знать не должен и которые никак не влияют на выполнение программы, на мой взгляд, совершенно бессмысленно.
То что все меняется — это понятно и никто (надеюсь) не рассчитывает что этот список сообщений будет вечен
А вто то что ни нигде не опубликованы — это плохо т.к. писать программу надо здесь и сейчас, на этой версии языка, а не на некоей идеальной, которая когда-то появится.
Я это не к тому, что надо все бросать и делать немедленно этот список
В языке пока есть много принципиальных проблем, которые меня лично волнуют значительно больше чем список сообщений, типа практически виснущего процесса компиляции на некоторых инлайновых функций или рразмножение одинаковых классов при использовнии ::StatFunction.
Для меня лично отсутствие списка ошибок особой проблемы не составляет т.к. "на скорость не влияет"
У приватных пропертей нет гетеров
Да и не в этом суть
Это публичная функция, что и как она использует внутри своей реализации никого за ее пределами волновать не должно и от того что она inline ничего не меняется
Т.к. функция inline, то все ее тело подставляется в место использования и как бы получается что приватные поля и методы "используются" за пределами класса.
Я голосую за обыкновенный баг.
Я знаю несколько способов обойти описанную проблему, к описанному выше еще можно добавить "?.let", но вопрос был не об этом.
Есть ли какие-то подтверждения того, что запрет на smart cast растет именно из "потенциальной неодинаковости getter-а", а не из-за многопоточности?
Этот пример говорит об обратном:
Ошибка точно та же, гетеров нет. То же и с "@JvmField".
Да, скорее всего, будут что-то менять.
Я лично на это даже надеюсь :)
Пока я каких-то проблем не испытывал.
Вот сегодня (вчера) прилетела обнова языка и в ней оказались ампутированными битовые операции для типов Short и Byte. Пришлось править кусок либы и я уже хотел по этому поводу расстроиться, но потом посмотрел на реализацию и на Java и, в общем-то, причина этого действия стала ясна. Меня "убедили" в адекватности этого действия.
Пока это было максимальное, на что я нарывался.
Да и, на мой взгляд, движуха в языке не является особой проблемой.
В любой развивающейся системе будут изменения — этого не избежать.
Я лично пришел к следующему рецепту: при обновлении смотрю на ньюсы и, если количество решенных проблем или интересных фич перевешивает трудозатраты на адаптацию, то перехожу; если нет — сижу на старой версии.
Это я по опыту изменений, которые приходилось вносить с принципиальным перелопачиванием многих сотен кб сорсов. В Kotlin-же я пока не видел ничего даже отданно схожего по трудозатратам.
Я лично выбрал этот язык с прицелом именно на андроид т.к. остальные альтернативы мне показались значительно хуже либо синтаксически и стилистически (например Scala), или принципиально (например, нетипизированный Groovy).
На мой взгляд, именно Kotlin максимально близок к Swift, но, возможно Вам лучше подойдет что-то другое т.к. иногда лучше перейти на что-то совсем другое, чем "очень похожее, но совсем не такое в мелочах" — будет меньше ошибок и расстройств.
Меня просто поржает: с чего такая агрессивность-то?
Наследие "кг\ам" или просто день не задался?
Если я чем умудрился обидеть, то прошу прощения.
В комменте, практически в каждом пункте текст, который вызван простым непониманием вопроса в статье.
Не проблема, я не заставляю этот текст читать, тем более что, видимо, это противно.
Это взаимно, так что на этом прощаюсь
За пару часов язык в принципе освоить невозможно и, соответственно, делать о нем какие-то выводы сложно.
Свифт, наверное, хорош (когда возникла необходимость писать под иос я, взглянув на синтаксис objective-C сказал что буду это делать только за очень отдельные деньги, и вопрос с тех пор не поднимался, жаль тогда не было свифта) но, к сожалению, за пределами одной платформы его не существует.
Если же возникает задача для андроида, то, на мой взгляд, Kotlin — это наилучший выбор.
Уж в сравнении с явой-то точно.
Это объяснение уже начинает иметь какой-то смысл кроме абстракций, спасибо.
Есть какие-то подтверждения этого?
Кратенько, по существу т.к. придирки и упражнения с схоластике не особо интересны.
То что сейчас в Kotlin — это foreach, который именно в таком виде завели в каком-нить С# именно для того, чтобы обозначить его нишу.
Мне, по сути, без разницы как оно называется.
У меня претензия к отсутствию альтернативы нормального for. Считайте его хоть из С хоть из Java.
Это неправда.
Посмотрите генерируемый код.
А на стыке Java\Kotlin как раз проверок не будет вообще, если на стороне Kotlin явно не указан "?"-й тип.
В Java не нужно обеспечивать синхронизацию? Все операции\функции\блоки… атомарны? Компилятор как-то автоматически за меня определит границы блока синхронизации и создаст для них код?
Если нет, то аргумент не принимается.
ПС: Я не знаю языков где "объект привязан к какому-то потоку". Такие существуют?
Смысла нет
Об том и спич :)
Наоборот.
Специально для внешнего кода убрали проверки.
Находил описание, когда наступил на эти грабли в каком-то парсере и начал искать почему в коде нет проверок.
Полное содержимое кейса я не помню, но смысл был в том, что при наличии проверок ломался какой-то код.
Сейчас нулабле-тип объявленный в Kotlin имеет тип "?", а из Java "!".
Для первого проверки производятся, и выдаются все предупреждения, а для второго нет.
Согласен, break реализовать в коде сложно.
Я так понимаю, ты намекаешь на то, что никто не мешает исправить существующие классы Java и добавить в них недостающие аннотации?
Действительно, в нем декларируется "Ceylon's type system is fully reified at runtime" и в качестве примера приводят именно "if (is Map<String,Object> map)".
Интересно, какой ценой они этого добились?
Усложняет, разумеется, не наличие бесполезного цикла, а отсутствие полезного.
Фор — это очень удобная и краткая конструкция с двумя выражениями и одним условием.
Она короткая и очень наглядная.
Для меня лично, разворачивание его в while с отдельным описанием переменных, значительно снижает читаемость кода.
Усложняет, разумеется, не наличие бесполезного цикла, а отсутствие полезного.
Хмм… не понимаю о чем речь.
Можете привести пример?
Можете привести пример ее осмысленного использования?
Довольно давно есть:
https://discuss.kotlinlang.org/t/compiller-works-very-slow-for-big-amout-of-inlined-code/2234/2
Да, извиняюсь, не сообразил с доступом.
Тем не менее (и даже более), выдавать сообщения основанные на внутренних собенностях реализации, о которых никто знать не должен и которые никак не влияют на выполнение программы, на мой взгляд, совершенно бессмысленно.
То что все меняется — это понятно и никто (надеюсь) не рассчитывает что этот список сообщений будет вечен
А вто то что ни нигде не опубликованы — это плохо т.к. писать программу надо здесь и сейчас, на этой версии языка, а не на некоей идеальной, которая когда-то появится.
Я это не к тому, что надо все бросать и делать немедленно этот список
В языке пока есть много принципиальных проблем, которые меня лично волнуют значительно больше чем список сообщений, типа практически виснущего процесса компиляции на некоторых инлайновых функций или рразмножение одинаковых классов при использовнии
::StatFunction.Для меня лично отсутствие списка ошибок особой проблемы не составляет т.к. "на скорость не влияет"
У приватных пропертей нет гетеров
Да и не в этом суть
Это публичная функция, что и как она использует внутри своей реализации никого за ее пределами волновать не должно и от того что она inline ничего не меняется
Т.к. функция inline, то все ее тело подставляется в место использования и как бы получается что приватные поля и методы "используются" за пределами класса.
Я голосую за обыкновенный баг.