AN
fun Number.toChar() = toInt().toChar()Size: a a a
2020 December 27
IP
@y9san9 @noraltavir единственно правильным дизайном было бы сделать
AN
В жаве хреновый дизайн, в котлин хреновый интероп с этим дизайном
IP
@y9san9 @noraltavir единственно правильным дизайном было бы сделать
fun Number.toChar() = toInt().toChar()а в инте иметь toChar ну просто как метод в классе
VP
в общем, если не указывать тип, то оно вызовет toChar и получит 42, как и надо. а если указать тип, то оно не будет знать, есть ли там toChar и вставит intValue (который забриджован к toInt), а потом I2C
Это ещё норм, они всё равно должны возвращать одинаковые значения.
Вот исходный баг с NoSuchMethod - это бомба.
Вот исходный баг с NoSuchMethod - это бомба.
IP
Это ещё норм, они всё равно должны возвращать одинаковые значения.
Вот исходный баг с NoSuchMethod - это бомба.
Вот исходный баг с NoSuchMethod - это бомба.
это не такая уж бомба, потому что Integer никто не использует
IP
но вообще говоря
IP
эта же ошибка есть, например, для BigInteger
VP
это не такая уж бомба, потому что Integer никто не использует
Компилятор вставил вызов метода, которого нет, ну wtf
IP
Компилятор вставил вызов метода, которого нет, ну wtf
wtf, на который тяжело наткнуться. а вот у длинной арифметики таки есть юзкейсов
VP
Много что почти никто не использует, а потом пишешь что-нибудь и на 1-2 таких прикола обязательно натыкаешься 😒
IP
в общем, чем больше копаешься в компиляторе котлина и его багах, тем больше разочароываыаешься
AN
К сожалению, конкретно Number-ы проектировались очень давно и теперь надо тащить совместимость. Задизайнить их хорошо вообще сложно. Но вероятно, надо было бы делать вообще с маркерным интерфейсом и конверсией через эктеншены
IP
К сожалению, конкретно Number-ы проектировались очень давно и теперь надо тащить совместимость. Задизайнить их хорошо вообще сложно. Но вероятно, надо было бы делать вообще с маркерным интерфейсом и конверсией через эктеншены
так я выше написал, как надо было делать.
class Number {
fun toInt(): Int
}
class Int : Number {
fun toChar(): Char
}
fun Number.toChar() = toInt().toChar()
class Number {
fun toInt(): Int
}
class Int : Number {
fun toChar(): Char
}
fun Number.toChar() = toInt().toChar()
AN
К сожалению, конкретно Number-ы проектировались очень давно и теперь надо тащить совместимость. Задизайнить их хорошо вообще сложно. Но вероятно, надо было бы делать вообще с маркерным интерфейсом и конверсией через эктеншены
Или через силед класс, где все кастомные числа вынесены отдельно
AN
так я выше написал, как надо было делать.
class Number {
fun toInt(): Int
}
class Int : Number {
fun toChar(): Char
}
fun Number.toChar() = toInt().toChar()
class Number {
fun toInt(): Int
}
class Int : Number {
fun toChar(): Char
}
fun Number.toChar() = toInt().toChar()
Ну это исправляет косяк котлин, но не исправляет исходного дизайна
IP
Или через силед класс, где все кастомные числа вынесены отдельно
гораздо сложнее реализовать
AN
гораздо сложнее реализовать
Ну так дизайн фундаментальных фич - это не просто.
L
Переслано от LevT
Да, я дошёл до некоего предела,
Есть запрос на DSL для тестовых данных
Чем здесь в котлине для меня богато?
val data: = listOf(здесь уже то ли я не могу уследить за скобками, то ли котлин путается и не может сконструировать то, что я хочу
(listOf ("buy" to 2)) to (listOf(50, 465, 100, 8, 557) to "I have enough resources, making you a coffee!"),
(listOf("buy" to 2, "buy" to 2)) to (listOf(50, 465, 100, 8, 557) to "Sorry, not enough water!"),
(listOf("buy" to 2, "buy" to 2, "fill" to listOf(1000, 0, 0, 0)) to (listOf(1050, 465, 100, 8, 557) to ""),
(listOf("buy" to 2, "buy" to 2, "fill" to listOf(1000, 0, 0, 0)), "buy" to 2) to (listOf(700, 390, 80, 7, 564) to "I have enough resources, making you a coffee!")
// (listOf("buy" to 2, "buy" to 2, "fill" to listOf(1000, 0, 0, 0)), "buy" to 2, "take" to "") to (listOf(700, 390, 80, 7, 564) to "I gave you $564"),
)
Есть запрос на DSL для тестовых данных
Чем здесь в котлине для меня богато?