AN
А где реализация-то будет? Все равно тебе надо на каждый A реализацию делать
Size: a a a
2020 December 30
IP
А где реализация-то будет? Все равно тебе надо на каждый A реализацию делать
не надо же. потому что BufferFactory дает метод new от произвольного типа
AN
не надо же. потому что BufferFactory дает метод new от произвольного типа
Не может. В принципе. Он должен знать, что инстанцировать. Значит где-то это должно быть прописано.
ВМ
немного отвлечённый вопрос
и
работает так же быстро, как
и
sealed class A { class B: A; class C: A; class D: A } и
when (a) { is B -> fB(a); is C -> fC(a); is D -> fD(a) } работает так же быстро, как
abstract class A(val tp: Int) { class B: A(1); class C: A(2); class D: A(3) } и
when (a.tp) { 1 -> fB(a as B); 2 -> fC(a as C); 3 -> fD(a as D) }
?IP
Не может. В принципе. Он должен знать, что инстанцировать. Значит где-то это должно быть прописано.
а ему и не нужно ничего инстанцировать, т.к.:
interface BufferFactory<A<_> : Buffer<_>> {
fun <T> new(size: Int, init: (Int) -> T): A<T>
}AN
немного отвлечённый вопрос
и
работает так же быстро, как
и
sealed class A { class B: A; class C: A; class D: A } и
when (a) { is B -> fB(a); is C -> fC(a); is D -> fD(a) } работает так же быстро, как
abstract class A(val tp: Int) { class B: A(1); class C: A(2); class D: A(3) } и
when (a.tp) { 1 -> fB(a as B); 2 -> fC(a as C); 3 -> fD(a as D) }
?Что такое "работает быстро"? Перебор по типам очень шустрый на JVM. На JS не очень
AN
а ему и не нужно ничего инстанцировать, т.к.:
interface BufferFactory<A<_> : Buffer<_>> {
fun <T> new(size: Int, init: (Int) -> T): A<T>
}Так тебе все равно где-то надо к каждому A и Т где-то конструктор сопоставить. Хоть в имплиситах, хоть где
ВМ
во втором случае это вроде tableswitch на jvm
в первом непонятно
в первом непонятно
AN
во втором случае это вроде tableswitch на jvm
в первом непонятно
в первом непонятно
Такие вещи оптимизировать без острой нужды и явных замеров очень-очень не рекомендуется
IP
Так тебе все равно где-то надо к каждому A и Т где-то конструктор сопоставить. Хоть в имплиситах, хоть где
нужно, да
IP
т.к. нужно реализовать BufferFactory через Companion каждого конкретного буфера
AN
нужно, да
Воот. Суммарный объем кода будет ровно тот же самый. Разница только в том, что у нас надо явно фабрику передать, а с имплиситами они к типу байндятся. Одно слово разницы.
IP
но внешне оно выглядит полиморфно и тайпсейфно
AN
но внешне оно выглядит полиморфно и тайпсейфно
И если у тебя две фабрики на один тип, упс.
IP
И если у тебя две фабрики на один тип, упс.
то можно просто проименовать их и держать в разных переменных?
IP
class ListBuffer<T> {
companion object {
val A = BufferFactory<ListBuffer<_>> { ... }
val B = BufferFactory<ListBuffer<_>> { ... }
}
}AN
то можно просто проименовать их и держать в разных переменных?
Не, погоди. По типу же биндится. Это тебе надо на каждый чих ньютайпы тогда платить. Если биндится не по типу, а явной подстановкой, то оно и так уже работает.
IP
Не, погоди. По типу же биндится. Это тебе надо на каждый чих ньютайпы тогда платить. Если биндится не по типу, а явной подстановкой, то оно и так уже работает.
так оно в любом случае биндится через компаньон
IP
который по сути просто переменная
AN
так оно в любом случае биндится через компаньон
Тогда опять не понял, причем тут хкт. Ладно, пока отложим, работать надо.