Хороший, на мой взгляд, пример потенциального использования типов высшего порядка можно показать на таком примере:
trait Container<T> {
// some methods
}
fn map<T, C: Container<T>>(c: C<T>) -> C<T> {
// some code
}
Мы хотим на уровне сигнатуры функции выразить то, что функция map не только возвращает контейнер элементов того же типа, что аргумент, но и конкретная реализация контейнера у аргумента и возвращаемого значения тоже совпадает.
Бесспорно, это в разы удобнее, чем в Java. Подобное поведение реализовано в Rust. Конечно, там тоже не все так гладко, так как \ в конце строки так же убирает и сам перевод строки, и если он нужен, приходится вручную добавлять \n. Но лично для меня такая реализация выглядит несколько более приятной.
На самом деле все-таки не совсем без плясок.
Если важны отступы в строчках и одновременно хочется видеть красиво отформатированный код, то, насколько мне известно, сейчас нет способа это сделать в compile time. Вместо этого есть несколько костылей типого такого.
Также, одновременное отключения экранирования в многострочных строках (на самом деле они не многострочные, а просто сырые) и поддержка интерполяции в них приводят к конструкции ${'$'}, когда нужно чтобы строка содержала $.
Но ведь нет никакой магии в Smart Casts.
Просто если компилятор может вывести, что переменная на данном участке программы имеет более "узкий" тип, то компилятор позволяет использовать особенности этого типа, автоматически расставляя касты, если это нужно.
С точки зрения java/байткода это либо простой каст к подтипу, который бы в java пришлось ручками писать, либо же это каст от nullable типа к not nullable, что отражается только в том, что в коде можно писать . вместо ?. и никак не отражается в сгенерированном байткоде.
Соответственно это никак не отражается на памяти и производительности по сравнению с java.
Но nullable типы в котлине не создавались для замены исключений, и использование их так, как описано в вашем примере, действительно плохо с точки зрения api метода, если информация о ошибке важна для пользователя.
Nullable типы введены в язык, чтобы на уровне компилятора обнаруживать потенциальные NPE и выводить ошибку компиляции там, где в джаве это было бы NPE в рантайме. То есть использование nullable типов это тоже самое, что использование Optional, только на уровне синстаксиса языка.
*нужно не забывать обновлять страницу перед отправкой коммента*
https://spring.io/blog/2016/02/15/developing-spring-boot-applications-with-kotlin
https://kotlinlang.org/docs/tutorials/spring-boot-restful.html
не сказал бы что это прям гайды, просто несколько фактов, которые полезно знать. А в целом гайды нужны именно для использования Spring, а уж использование его в Kotlin ничем не отличается от использования апи других библиотек/фрэймворков
если же интересуют именно подобные посты на хабре, то да, тут были несколько:
https://habrahabr.ru/post/274997/
https://habrahabr.ru/post/274713/
Чтобы не было выделения памяти при промежуточных операциях можно/нужно использовать Sequence (однопоточный аналог Stream). Для него есть те же методы, но возвращают они тоже Sequence.
Если говорить именно об ACP ICPC, то для выступления за вуз определенной страны не нужно быть гражданином этой страны. Так что вполне возможна ситуация, что за американский вуз выступают совсем не граждане США.
«Почему?»
Ответ может показаться довольно глупым, но все же: потому что пример таков. То есть в самом примере заложено сравнение многомерной (для нас с вами как минимум трехмерной) вселенной именно с двухмерной поверхностью, так как человек саму ситуацию может представить, а сам пример демонстрирует, как может существовать расширяющийся объект без краев, и как любые две точки будут удаляться друг от друга при расширении.
«А внутри шарика что тогда?»
Ничего — этого пространства для данной «двухмерной вселенной» не существует, так же как для нас с вами непостижима четвертая координата, так как мы воспринимаем мир трехмерным. Собственно в этом и проблема. У такой сферы, неважно скольки мерной, геометрический центр находится вне самой сферы — в шаре, который представляет собой объект, хотя бы на 1 размерность больше самой сферы.
У шарика есть центр, если рассматривать его как трехмерный объект в трехмерном пространстве. Но в подобном сравнении вселенная — это не сам шар, а именно его двухмерная оболочка, а вот у нее уже довольно сложно определить центр. Вот вселенная в довольно бытовом понимании ведет себя, как эта оболочка только трехмерная (трехмерная для нас с вами, естественно).
Читаю. Даже больше скажу, когда я его писал 2 дня назад еще ни одного подобного комментария не было, но вот модерация его прошла не слишком быстро и в итоге тут уже целая ветка обсуждений
Отключите
buildSearchableOptionsтаск и будет ваш счастьеТак же автор того курса перевыложил сам курс 2018 года
https://cs140e.sergio.bz/
А в чем собственно была проблема? и как давно это было?
Не в создании нового проекта случайно?
Хороший, на мой взгляд, пример потенциального использования типов высшего порядка можно показать на таком примере:
Мы хотим на уровне сигнатуры функции выразить то, что функция
mapне только возвращает контейнер элементов того же типа, что аргумент, но и конкретная реализация контейнера у аргумента и возвращаемого значения тоже совпадает.Бесспорно, это в разы удобнее, чем в Java.
Подобное поведение реализовано в Rust. Конечно, там тоже не все так гладко, так как
\в конце строки так же убирает и сам перевод строки, и если он нужен, приходится вручную добавлять\n. Но лично для меня такая реализация выглядит несколько более приятной.На самом деле все-таки не совсем без плясок.
Если важны отступы в строчках и одновременно хочется видеть красиво отформатированный код, то, насколько мне известно, сейчас нет способа это сделать в compile time. Вместо этого есть несколько костылей типого такого.
Также, одновременное отключения экранирования в многострочных строках (на самом деле они не многострочные, а просто сырые) и поддержка интерполяции в них приводят к конструкции
${'$'}, когда нужно чтобы строка содержала$.Но ведь нет никакой магии в Smart Casts.
Просто если компилятор может вывести, что переменная на данном участке программы имеет более "узкий" тип, то компилятор позволяет использовать особенности этого типа, автоматически расставляя касты, если это нужно.
С точки зрения java/байткода это либо простой каст к подтипу, который бы в java пришлось ручками писать, либо же это каст от nullable типа к not nullable, что отражается только в том, что в коде можно писать
.вместо?.и никак не отражается в сгенерированном байткоде.Соответственно это никак не отражается на памяти и производительности по сравнению с java.
Nullable типы введены в язык, чтобы на уровне компилятора обнаруживать потенциальные NPE и выводить ошибку компиляции там, где в джаве это было бы NPE в рантайме. То есть использование nullable типов это тоже самое, что использование Optional, только на уровне синстаксиса языка.
*нужно не забывать обновлять страницу перед отправкой коммента*
Так а зачем гадать? можно же просто взять и посмотреть в офф репозиторий. Там первым предложением в readme написано:
Так что да — нативный код будет генерироваться через LLVM, что в скорее плюс, чем минус.
https://kotlinlang.org/docs/tutorials/spring-boot-restful.html
не сказал бы что это прям гайды, просто несколько фактов, которые полезно знать. А в целом гайды нужны именно для использования Spring, а уж использование его в Kotlin ничем не отличается от использования апи других библиотек/фрэймворков
если же интересуют именно подобные посты на хабре, то да, тут были несколько:
https://habrahabr.ru/post/274997/
https://habrahabr.ru/post/274713/
Ответ может показаться довольно глупым, но все же: потому что пример таков. То есть в самом примере заложено сравнение многомерной (для нас с вами как минимум трехмерной) вселенной именно с двухмерной поверхностью, так как человек саму ситуацию может представить, а сам пример демонстрирует, как может существовать расширяющийся объект без краев, и как любые две точки будут удаляться друг от друга при расширении.
«А внутри шарика что тогда?»
Ничего — этого пространства для данной «двухмерной вселенной» не существует, так же как для нас с вами непостижима четвертая координата, так как мы воспринимаем мир трехмерным. Собственно в этом и проблема. У такой сферы, неважно скольки мерной, геометрический центр находится вне самой сферы — в шаре, который представляет собой объект, хотя бы на 1 размерность больше самой сферы.