(
Над кем именно и зачем?
Над структурой, которой я передаю параметр "тайпкласса"
Size: a a a
2020 June 25
AN
Над структурой, которой я передаю параметр "тайпкласса"
а кто мешает-то?
VP
Над структурой, которой я передаю параметр "тайпкласса"
Не вижу проблем
VP
Передаётся он при создании, дальше просто пользуешься
AN
fun RealField.cosh(arg: Number) = cosh(arg.toDouble)(
Передаётся он при создании, дальше просто пользуешься
Показываю:
fun <K, K1> Tree<K, T>.mapKey(F: Field<K1>, f: (K) -> K1): Tree<K1, T>
AN
Передаётся он при создании, дальше просто пользуешься
и все его экстеншены тащишь за собой. При этом эктсешены видны только в том проекте, где они определены
AN
Показываю:
fun <K, K1> Tree<K, T>.mapKey(F: Field<K1>, f: (K) -> K1): Tree<K1, T>
тогда нужен маппер для филда таскать
VP
Показываю:
fun <K, K1> Tree<K, T>.mapKey(F: Field<K1>, f: (K) -> K1): Tree<K1, T>
Операция, конечно, интересная, но действительно ли тебе такое надо?
VP
Больше похоже на оверинжиниринг
(
Операция, конечно, интересная, но действительно ли тебе такое надо?
Что значит надо или не надо?
Операция, конечно, интересная, но действительно ли кому бы то ни было такое надо? Такой же вопрос
fun <T, R> List<T>.map(f: (T) -> R): List<R>
Операция, конечно, интересная, но действительно ли кому бы то ни было такое надо? Такой же вопрос
VP
Что значит надо или не надо?
Операция, конечно, интересная, но действительно ли кому бы то ни было такое надо? Такой же вопрос
fun <T, R> List<T>.map(f: (T) -> R): List<R>
Операция, конечно, интересная, но действительно ли кому бы то ни было такое надо? Такой же вопрос
А у мапы в stdlib есть mapKeys?
(
А у мапы в stdlib есть mapKeys?
да
VP
да
Ну ок. Но ты легко можешь сделать mapKeysTo.
AN
Показываю:
fun <K, K1> Tree<K, T>.mapKey(F: Field<K1>, f: (K) -> K1): Tree<K1, T>
А эта операция кстати никогда не будет работать нормально, потому что нет гарантии, что для типа будет тайп класс нужный. Ну и кстати, если уж прижгло, можно сделать свой
inline fun <reified: T> fieldFor<T>: Field<T>. Будет совсем как в хаскеле.(
А эта операция кстати никогда не будет работать нормально, потому что нет гарантии, что для типа будет тайп класс нужный. Ну и кстати, если уж прижгло, можно сделать свой
inline fun <reified: T> fieldFor<T>: Field<T>. Будет совсем как в хаскеле.Будет. Я не смогу её вызвать, если не будет тайпкласса
(
Ну ок. Но ты легко можешь сделать mapKeysTo.
Типа, в какую-то такую же структуру? Не пойдет, у меня иммутабельно
(
Тут причем даже не какие-то личные пристрастия, а просто иммутабельное дерево было сделать легче
VP
Типа, в какую-то такую же структуру? Не пойдет, у меня иммутабельно
Ну что ж, тогда в подобных операциях придётся всё-таки принимать этот объект. Но это надо только если тип ключей меняется. Не очень верится, что это часто нужно.
(
Ну что ж, тогда в подобных операциях придётся всё-таки принимать этот объект. Но это надо только если тип ключей меняется. Не очень верится, что это часто нужно.
Да элементарно, тестировать на интах, в проде гонять на лонгах хотя бы