Как раз нашёл статью где сравниваются два подхода — instanceOf и enum, с instanceOf медленнее, хоть и красивее. habr.com/ru/post/430014
По моему идея прятать не очень красивые, но более эффективные решения в глубины кода в целом неплохая. А то если совсем не заглядывать под капот, то можно получить проблемы с производительностью (но тут речь скорее про библиотеки, а не прикладные программы)
Ну из за особенностей синтаксиса я не мог написать на котлине точно так же как на Scala. Со сложными случаями выглядит интересно, спасибо почитаю.
_ match {
case Circle(x, y, radius) => println(s"$x, $y, $radius")
case Rectangle(x0, y0, x1, y1) => println(s"$x0, $y0, $x1, $y1")
}
внутри содержит instanceof (посмотрел декомпилированный код). А я как раз хотел показать пример где instanceof не используется и компилятор нуждается в подсказке.
Код на котлине эквивалентеый вашему коду на Scala
when(figure){
is Circle -> with(figure) { println("$x $y $radius") }
is Rectangle -> with(figure) { println("$x0 $y0 $x1 $x1") }
}
С одной стороны когда допилят компилятор такие штуки станут не особо нужны. Но с другой стороны мы можем проверять тип неявно, но при этом быть уверены что тип будет именно тот который нам нужен. Например мы добавляем всем потомкам поле type, по которому можем узнать класс. (Я не уверен насколько оправдано такое решение, но вроде бы оно может быть быстрее чем «x is A»)
код
enum class FigureType {
CIRCLE, RECTANGLE
}
sealed class Figure {
internal abstract val type: FigureType
}
class Circle(val x: Int, val y: Int, val radius: Int) : Figure() {
override val type = FigureType.CIRCLE
}
class Rectangle(val x0: Int, val y0: Int, val x1: Int, val y1: Int) : Figure() {
override val type = FigureType.RECTANGLE
}
@ExperimentalContracts
fun Figure.isCircle(): Boolean {
contract {
returns(true) implies (this@isCircle is Circle)
}
return type == FigureType.CIRCLE
}
@ExperimentalContracts
fun Figure.isRectangle(): Boolean {
contract {
returns(true) implies (this@isRectangle is Rectangle)
}
return type == FigureType.RECTANGLE
}
@ExperimentalContracts
fun test(figure: Figure) {
when {
figure.isCircle() -> {
println(figure.x)
println(figure.y)
println(figure.radius)
}
figure.isRectangle()-> {
println(figure.x0)
println(figure.y0)
println(figure.x1)
println(figure.y1)
}
}
}
Само по себе не сработает, но для этого в Kotlin есть специальная штука — контракты (тут важно заметить что компилятор не проверяет гарантии и можно всё сломать). И я не уверен, но у них вроде бы еще экспериментальный статус (как раз потому что можно всё сломать ими).
fun isNotEmptyString(obj: Any):Boolean {
contract {
returns(true) implies (obj is String)
}
return (obj is String) && obj.isNotEmpty()
//return (obj is Int) && obj > 0 //still valid with contract
}
Возможно негативно относятся к идее самостоятельной модификации автомобиля (который средство повышенной опасности)?
Так как я не автомобилист то хотел уточнить парктроник просто выводит информацию от датчиков на дисплей и динамик и никак не связан с другими системами автомобиля?
То есть проблемы возможны только в том случае если водитель за рулём не знает о модификации и паркуется "по приборам"?
На некоторых МРТ снимках, с которыми я работал, первый кадр содержит данные о пациенте в виде картинки в формате DICOM. Если отдавать сырые данные нейронной сети без их просмотра вполне можно пропустить такое.
У вас очевидно что слишком синтетический пример, исключения подразумевают что они случаются достаточно редко (собственно потому они и называются исключения).
Если в показанном выше примере не каждый раз передавать null, а один раз из 100, то производительность варианта с try… catch будет в двое хуже. А если один раз из 1000, то разница в производительности будет почти незаметна (проверил у себя на компе).
Главный плюс исключений это прозраная передача потока управления наверх (разумеется когда это необходимо).
PS и да наверное лучше возвращать не 0, а -1. А еще лучше Optional, как уже написали.
В оригинале написано «Find the intersection of two arrays». И в этом случае, операция пересечения множеств коммутативна. Зачем было переводить как «Как найти общие элементы двух массивов» непонятно.
Ну эта статья появилась у меня в подписке из тэга java, внимательно прочитав всю статью, я не нашёл ничего связанного с java(кроме общих слов). Какой реакции вы ожидали?
А он коммерческий?
Текстовые сообщения 0.003 руб за шт. в день
Сообщения с картинками 0.0035 руб за шт. в день
Сообщения с файлами 0.0035 руб за шт. в день
Сообщения с шепотом (бесплатно)
Я кстати так и не смог понять что значит «Сообщения с шепотом» и чем они отличаются от обычных?
По моему идея прятать не очень красивые, но более эффективные решения в глубины кода в целом неплохая. А то если совсем не заглядывать под капот, то можно получить проблемы с производительностью (но тут речь скорее про библиотеки, а не прикладные программы)
Ну из за особенностей синтаксиса я не мог написать на котлине точно так же как на Scala. Со сложными случаями выглядит интересно, спасибо почитаю.
внутри содержит instanceof (посмотрел декомпилированный код). А я как раз хотел показать пример где instanceof не используется и компилятор нуждается в подсказке.
Код на котлине эквивалентеый вашему коду на Scala
Тут подробнее
Возможно негативно относятся к идее самостоятельной модификации автомобиля (который средство повышенной опасности)?
Так как я не автомобилист то хотел уточнить парктроник просто выводит информацию от датчиков на дисплей и динамик и никак не связан с другими системами автомобиля?
То есть проблемы возможны только в том случае если водитель за рулём не знает о модификации и паркуется "по приборам"?
На некоторых МРТ снимках, с которыми я работал, первый кадр содержит данные о пациенте в виде картинки в формате DICOM. Если отдавать сырые данные нейронной сети без их просмотра вполне можно пропустить такое.
Правительство запрещает
https://elementy.ru/Library6/p162.htm
Насколько я понимаю подход описанный в статье один в один скопирован из C#.
PS: мне тоже вариант из Котлина кажется удобнее.
"Для новичков Java может показаться немного." — вы случайно?
Java Language Specification 6.6.1:Более того я затрудняюсь представить себе язык где это не так.
Если в показанном выше примере не каждый раз передавать null, а один раз из 100, то производительность варианта с try… catch будет в двое хуже. А если один раз из 1000, то разница в производительности будет почти незаметна (проверил у себя на компе).
Главный плюс исключений это прозраная передача потока управления наверх (разумеется когда это необходимо).
PS и да наверное лучше возвращать не 0, а -1. А еще лучше Optional, как уже написали.
Текстовые сообщения 0.003 руб за шт. в день
Сообщения с картинками 0.0035 руб за шт. в день
Сообщения с файлами 0.0035 руб за шт. в день
Сообщения с шепотом (бесплатно)
Я кстати так и не смог понять что значит «Сообщения с шепотом» и чем они отличаются от обычных?