D
Кстати, а как часто люди импортируют
listOf() не из stdlib, а чужой?val a = [1, 2, 3] будет работать как val a = specialListOf(1, 2, 3)Size: a a a
2020 October 14
D
Вроде, ничего страшного не случится, если
с#
Вроде, ничего страшного не случится, если
val a = [1, 2, 3] будет работать как val a = specialListOf(1, 2, 3)страшно вообще-то)
не понять сходу что там вообще создается
не понять сходу что там вообще создается
D
страшно вообще-то)
не понять сходу что там вообще создается
не понять сходу что там вообще создается
Э. Список? :)
AH
Вроде, ничего страшного не случится, если
val a = [1, 2, 3] будет работать как val a = specialListOf(1, 2, 3)А там внезапно итерация наоборот!
M
проблема скорее всего будет как с тернарным оператором - будет непонятно использовать литералы или listOf()
D
А там внезапно итерация наоборот!
И кто же ее туда подсунет? Злобные разработчики компилятора? :)
D
проблема скорее всего будет как с тернарным оператором - будет непонятно использовать литералы или listOf()
В тернарнике это не основная проблема (см доклад позавчерашний) :)
M
В тернарнике это не основная проблема (см доклад позавчерашний) :)
ну одна из проблем - двойной api для одной и той же операции
D
И кто же ее туда подсунет? Злобные разработчики компилятора? :)
Вероятность этого равна вероятности того, что
listOf() будет возвращать Map, не? :)D
ну одна из проблем - двойной api для одной и той же операции
listOf()
ArrayList()
с#
ну одна из проблем - двойной api для одной и той же операции
хз. сейчас можно писать ифы с одним стейтментом со скобками или без. и вроде это не проблема
AM
проблема скорее всего будет как с тернарным оператором - будет непонятно использовать литералы или listOf()
Не упоминайте тернарник всуе. :)
AN
ну одна из проблем - двойной api для одной и той же операции
А как насчет
listOf<ArrayList>()? Это довольно легко сделатьD
Суть
listOf() в том, что команда stdlib сказала: вот вам способ создавать какой-то список вместо вызова конкретного конструктора. В application oriented языке нам по сути и не очень важно что за имплементация внутри.AN
Тут была бурная дискуссия в офтопе по поводу декораторов. Не буду транслировать, но
1) отдельным представителям не нравится то, что теряется прозрачность языка ( в принципе здравый аргумент, по декоратору сложно понять сигнатуру функции, если он ее меняет)
2) @y9san9 высказал здравую мысль о том, что надо иметь доступ к сигнатуре функции в декараторе, чтобы делать например кэш с именами).
3) Людей покусал спринг и декораторы больно похожи на аннотации.
1) отдельным представителям не нравится то, что теряется прозрачность языка ( в принципе здравый аргумент, по декоратору сложно понять сигнатуру функции, если он ее меняет)
2) @y9san9 высказал здравую мысль о том, что надо иметь доступ к сигнатуре функции в декараторе, чтобы делать например кэш с именами).
3) Людей покусал спринг и декораторы больно похожи на аннотации.
AN
Тут была бурная дискуссия в офтопе по поводу декораторов. Не буду транслировать, но
1) отдельным представителям не нравится то, что теряется прозрачность языка ( в принципе здравый аргумент, по декоратору сложно понять сигнатуру функции, если он ее меняет)
2) @y9san9 высказал здравую мысль о том, что надо иметь доступ к сигнатуре функции в декараторе, чтобы делать например кэш с именами).
3) Людей покусал спринг и декораторы больно похожи на аннотации.
1) отдельным представителям не нравится то, что теряется прозрачность языка ( в принципе здравый аргумент, по декоратору сложно понять сигнатуру функции, если он ее меняет)
2) @y9san9 высказал здравую мысль о том, что надо иметь доступ к сигнатуре функции в декараторе, чтобы делать например кэш с именами).
3) Людей покусал спринг и декораторы больно похожи на аннотации.
На мой персональный взгляд неявность типов в сигнатуре - это дайствительно проблема серьезная (то же про лямбды)
с#
На мой персональный взгляд неявность типов в сигнатуре - это дайствительно проблема серьезная (то же про лямбды)
а ведь можно было завезти декораторы как делегаты
fun fibonacci(at: Int) by memoized {
}
fun fibonacci(at: Int) by memoized {
}
с#
тут уже проблема неявности типов куда меньше
AL
Тут была бурная дискуссия в офтопе по поводу декораторов. Не буду транслировать, но
1) отдельным представителям не нравится то, что теряется прозрачность языка ( в принципе здравый аргумент, по декоратору сложно понять сигнатуру функции, если он ее меняет)
2) @y9san9 высказал здравую мысль о том, что надо иметь доступ к сигнатуре функции в декараторе, чтобы делать например кэш с именами).
3) Людей покусал спринг и декораторы больно похожи на аннотации.
1) отдельным представителям не нравится то, что теряется прозрачность языка ( в принципе здравый аргумент, по декоратору сложно понять сигнатуру функции, если он ее меняет)
2) @y9san9 высказал здравую мысль о том, что надо иметь доступ к сигнатуре функции в декараторе, чтобы делать например кэш с именами).
3) Людей покусал спринг и декораторы больно похожи на аннотации.
Ну последнее спорно, в питоне и js/ts декораторы ровно так и выглядят, насколько я помню
Но хотя идейно да, получается, что один и тот же синтаксис будет для трёх довольно разных вещей:
1. Аннотации
2. Требования контекста какого-то класса (
3. Собственно декорирование функции (
Но хотя идейно да, получается, что один и тот же синтаксис будет для трёх довольно разных вещей:
1. Аннотации
2. Требования контекста какого-то класса (
@with<View> )3. Собственно декорирование функции (
@withTransaction )