
Жабра
29.06.2018
15:07:14

Quantum Harmonizer
29.06.2018
15:07:29

Жабра
29.06.2018
15:07:38

Quantum Harmonizer
29.06.2018
15:08:04

Google

Жабра
29.06.2018
15:21:17

Quantum Harmonizer
29.06.2018
15:21:37

Жабра
29.06.2018
15:22:18
код?
https://gist.github.com/indrih17/6ab3e5181c16c505970fe90768248529

Quantum Harmonizer
29.06.2018
15:24:17

Жабра
29.06.2018
15:28:20

Quantum Harmonizer
29.06.2018
15:28:35
Посмотри ещё в сторону TypeToken.getParameterized

Жабра
29.06.2018
15:29:06

Quantum Harmonizer
29.06.2018
15:29:16

Жабра
29.06.2018
15:29:46

Quantum Harmonizer
29.06.2018
15:30:26

Жабра
29.06.2018
15:31:14

Quantum Harmonizer
29.06.2018
15:35:40

Google

Жабра
29.06.2018
15:36:09

Quantum Harmonizer
29.06.2018
15:36:44

Жабра
29.06.2018
15:37:39
Пишет что
Cannot use 'T' as reified type parameter. Use a class instead

Quantum Harmonizer
29.06.2018
15:39:48
ну так потому что он не reified
inline fun <reified T> — и будет работать

Жабра
29.06.2018
15:40:49

Alexander
30.06.2018
05:16:33
Кто-нибудь видел приличный интерфейс для логирования на kotlin common?
А то у меня в большой библиотеке slf4j - еиднственная зависимость. Можно бы перенести все в common

Taras
30.06.2018
08:49:07

Alexander
30.06.2018
08:49:35
Нужно, но мне влом. И времени нет, поэтому вопрос, может кто уже написал.

Taras
30.06.2018
08:50:16
Я раньше муторился с этим, но потом забил.

Alexander
30.06.2018
08:51:27
Я нашел несколько проектов разной степени недоделанности
Вот вроде эта штука делает приблизительно то, что надо: https://github.com/shafirov/klogging
Но она какая-то не очень живая, кроме того, релизи на jitpack меня немного нервируют

Костя
30.06.2018
11:39:04
кто подскажет, можно ли в котлин как в java указывать сделать нечто подобное:
abstract fun getParser(): HtmlParser<PR>
override fun getParser(): HtmlParser<DetailedDiscount> = HtmlParserForDetailedDiscount.newInstance()
где HtmlParserForDetailedDiscount имплементит интерфейс HtmlParser
мне летит ошибка что он жестко просит HtmlParser а не его наследников
наследников нельзя получается ?

Google

Alexander
30.06.2018
11:41:45
В яве по-моему так тоже нельзя

Костя
30.06.2018
11:42:41
можно вроде

Alexander
30.06.2018
11:42:44
А зачемт так делать, можно же в типеоставить PR, или этот метод где-то еще наследником используется не по назначению?

Костя
30.06.2018
11:43:11
в типе оставить PR ?
не понял
просто у меня есть несколько парсеров разных
все реализуют интерфейс

Alexander
30.06.2018
11:43:56
```kotlin
override fun getParser(): HtmlParser<PR> = HtmlParserForDetailedDiscount.newInstance()
```

Костя
30.06.2018
11:44:00
но при отдаче их я вижу ошибку, что я пытаюсь отдать наследника, а в котлине типы жесткие наверно

Alexander
30.06.2018
11:44:08
Или использовать проекции

Костя
30.06.2018
11:44:12
оО
я ж наоборот PR заменяю тут уже на конкретный тип
т.к. каждый инстант парсера уже знает свой PR тип
всё равно не работает (

Alexander
30.06.2018
11:45:31
Так тот, кто этот метод исползует, все равно не сможет его узнать. Знать об этом будет только сам наследник
Вы же его будете использовать как интерфейс
В данном случае надо использовать <out PR>, тогда будет работать аналогично джавовскому <T extends PR>

Костя
30.06.2018
11:46:53
class HtmlConverterForDetailedDiscount : BaseConverter<DetailedDiscount>() {
override fun getParser(): HtmlParser<DetailedDiscount> = HtmlParserForDetailedDiscount.newInstance()
}
abstract class BaseConverter<PR> : Converter<ResponseBody, PR> {
abstract fun getParser(): HtmlParser<PR>
override fun convert(value: ResponseBody) = getParser().parse(value.string())
}
вот как это выглядит полностью

Google

Костя
30.06.2018
11:47:06
но увы не работает
пишет что
HtmlParserForDetailedDiscount.newInstance() возвращает тип не равный HtmlParser

Alexander
30.06.2018
11:52:48
Вот такой вариант компилируется:
class HtmlParser<PR>
class DetailedDiscount
abstract class BaseConverter<PR> {
abstract fun getParser(): HtmlParser<PR>
}
class HtmlConverterForDetailedDiscount : BaseConverter<DetailedDiscount>() {
override fun getParser(): HtmlParser<DetailedDiscount>{
return HtmlParser<DetailedDiscount>()
}
}
Так что проблема где-то в другом месте

Костя
30.06.2018
11:53:50
хм у вас получается 1 класс HtmlParser
а у меня это интерфейс
и у него несколько реализаций

Alexander
30.06.2018
11:54:07
И? какая разница

Костя
30.06.2018
11:54:53
в том что каждая реализация отдает себя
```
HtmlParserForDetailedDiscount.newInstance() возвращает тип не равный HtmlParser
```

Alexander
30.06.2018
11:54:58
Вот так тоже работает:
interface HtmlParser<PR>
class HtmlParserImpl<PR>: HtmlParser<PR>
class DetailedDiscount
abstract class BaseConverter<PR> {
abstract fun getParser(): HtmlParser<PR>
}
class HtmlConverterForDetailedDiscount : BaseConverter<DetailedDiscount>() {
override fun getParser(): HtmlParser<DetailedDiscount>{
return HtmlParserImpl<DetailedDiscount>()
}
}

Костя
30.06.2018
11:55:27
хм
сейчас применю к себе
погляжу что у меня не так
минутку

Alexander
30.06.2018
11:56:08
Нельзя подменять тип-параметра дженерика без предупреждения, я подозреваю, что вы где-то это и сделали
До чего же приятен котлиновский короткий синтаксис для таких примеров :) Можно классы в одну строчку делать

Костя
30.06.2018
11:59:42
всё бы ничего, но тут ещё есть
interface HtmlParser<PR>
class HtmlParserImpl<PR>: HtmlParser<PR> {
fun parse(str : String) : ___Type____
}
class DetailedDiscount
abstract class BaseConverter<PR> {
abstract fun getParser(): HtmlParser<PR>
}
class HtmlConverterForDetailedDiscount : BaseConverter<DetailedDiscount>() {
override fun getParser(): HtmlParser<DetailedDiscount>{
return HtmlParserImpl<DetailedDiscount>()
}
}
вот
в каждой имплементации парсера есть метод parse с конкретным типом уже
ну я так планировал )

Google

Костя
30.06.2018
12:00:34
я указал его ____Type____ сейчас там
как эту часть реализовать можно ?
метод parse пасит непосредственно в объекты уже

Alexander
30.06.2018
12:01:32
Я пока не вижу, в чем проблема

Костя
30.06.2018
12:01:38
нужно делать класс абстрактным ? HtmlParserImpl
и от него наследовать 2 инстанса и реализовывать у каждого уже parse ?

Alexander
30.06.2018
12:02:52
Ну в данном случае, если есть интерфей, то разумно абстрактый метод пихать в интерфейс, а потом уже плодить реализации
каждый impl будет со своим parse

Костя
30.06.2018
12:04:05
так а какой тип должен отдавать parse ?
PR ?
или конкретный

Alexander
30.06.2018
12:05:42
Идея интерфейса в принципе (не только в котлине) в том, что тот, кто его использует, не знает, как именно будет реализовано то, что внутри. А идея дженериков в том, что тип подставляется там, где дженерик актуализируется

Костя
30.06.2018
12:06:28
это я понимаю (

Alexander
30.06.2018
12:06:48
interface HtmlParser<PR>{
fun parse(str: String): PR
}
class HtmlParserImpl: HtmlParser<DetailedDiscount> {
override fun parse(str : String) : DetailedDiscount{
return ....
}
}

Костя
30.06.2018
12:06:51
я хочу в конкретной реализации парсера
да, так и было
да только будет ошибка
что HtmlParseImpl != HtmlParser<DetailedDiscount>
про что я писал