Что можно сделать с публичным методом-рашширением,...
# russian
l
Что можно сделать с публичным методом-рашширением, определенном в классе?
Copy code
class Test{
    val map = mapOf(
    	1 to "a",
        2 to "b"
    )
    fun Int.switch() = map[1] ?: "c"
}

fun main() {
    1.switch() ///???
    /////
}
g
Copy code
with (test){ 1.switch() }
но вообще странный подход "что можно сделать с тем-то". Отталкиваться лучше от задачи.
l
Да, я разделяю этот подход. Мне просто интересно.
А следующий вопрос вас наверно добьет
А зачем такое может понадобиться? 🙂
Подменять test?
g
в класс можно внедрить зависимости, элементарно
l
не понял
with (target){ dep.inject() }
Так чтоли?
g
есть у тебя
String.toDate()
глобальный. Завтра захочешь фенси форматтер какой-то использовать, может логер еще внутри. Твоя публичная функция очень быстро станет некрасивой, со всеми этими параметрами.
а так обернешь в какой-то
Mapper
, который это все спрячет
l
И как мне в toDate воткнуть зависимость?
Я не понял
g
зависимости будут в маппере,
toDate()
останется чистым
l
А ... как я их запихну то?
g
но у него будет контекст мапера
l
И надо будет везде писать with ?
g
это да, козявочка
l
with (mapper){ int.toDate() }
Ну... такое
Просто у меня как раз описанный вами пример ))) И я вот такой toDate с зависимостями... надоело уже писать
Но
with (mapper){ int.toDate() }
точно не то
g
можно на ты. Ну, да, на любителя.. Как и
CoroutineScope.foo()
в котором еще меньше практического смысла.
l
Наверно, можно через синглтон прокинуть в маппер то, что хочется - но я тогда потом не поменяю этот синглтон. Плохо.
g
удоли!111 про синглтон и никому не скажем.
l
Неее
Отталкиваться лучше от задачи.
Если в биз-логике прибито - синглтон - пиши синглтон.
Но... вот что я скажу
Да, тут рисково, что это может поменяться.
g
может веткой ошибся, не понял причем тут type erasure. Если хочешь это обсудить, то лучше создать отдельный тред 😉
l
type erasure ?
Это где?
g
хм, теперь у меня уже другой сниппет открылся)
до этого там были typealias
1.doMap(CustomMapper())
, не, это чет совсем уже непотребство какое-то
l
Это план Б
g
лучше уже олдскульный
mapper.doMap(1)
l
Что если маппер нужен "не тот"
Тогда цепочкой не попреобразуешь
Я хочу цепочкой
1.doMap().someProp.doOtherMap()
g
¯\_(ツ)_/¯
l
Мне чего колется - я вот так воткну, я ж не выну потом
А, фиги. Нету у меня глобального defaultMapper. Только через инъекцию.
Все, спасибо. Я воткну через делегата
g
удачи знатно воткнуть!
l
Не ты погоди
Помоему эпично получается
Только как кастомный использовать не пойму
Божечки мои, почему ж я логирование так не делал?
Твой with помог
g
о, ты один из тех троих, кто нашел применение Implementation by Delegation
l
Не ну шикарно же
Хотя да, я не совсем понимаю накой этот делегат
g
можно не писать
with
да, но я не знаю, если бы я хотел, чтобы мой Repository торчал наружу как Mapper.
но плюс за креативность)
l
А репозитори не подойдет
Сто пудов он не один. А интерфейс - один
А вот логи - хорошо подойдут.
Ну и моя возня с кэшем (в моей логике он один изначально)
a
Блин, а какой кейс практический из этого? Что-то понять не могу.(
l
Множественное наследование. Писать удобненько.