Мне одному показалось, что то, что анонсировал вчера Елизаров -

ну как-то такое себе... Сначала они объявляют нэймспейсы (я не понял, зачем) через очень странный синтаксис ("namespace<Type" очень уж выглядит как функция). Потом также добавляются мультиресиверы, но вместо человеческого "(Type1, Type2)" мы должны сделать обычный экстеншен, но не обычный экстеншен, потому что у него есть "with<Type2>" (и опять выглядит как что-то очень странное) (и вот так куча with, или подтипы через запятую?). Допекли меня декораторы, которые очевидны и легкочитаемы чуть более, чем никак (во всяком случае, мне так кажется). Это при том, что сам по себе декоратор очень легко можно сделать и без дополнительных модификаторов у функции (как мне кажется).

Или это я чего-то не понимаю, и это всё не просто так?

> Это при том, что сам по себе декоратор очень легко можно сделать и без дополнительных модификаторов у функции Можно, но круто, когда в языке есть поддержка декораторов с ёмким синтаксисом.

Вы просто, видимо, не сталкивались с тем, что комбинация нескольких функций превращает код в лесенку

Согласен про namespace

видать, бреслав там совсем в альтер ушел

Мне ещё интересно, кто это реализовывать будет, если мажорные баги годами висят без решений.

Да не, я имею ввиду, что декоратору НЕ обязательно иметь модификатор - он итак же получается принимает на вход лямбду и максимум - один ресивер

Ну и смотреть на синтаксис со слайдов бессмысленно. Эти фичи неизвестно когда будут, будут ли вообще, и уж тем более как именно будут выглядеть.

Давайте тогда на улучшения забьём, пока баги не пофиксят :)

сталкивался, но конкретно кейс из презентации - ОЧЕНЬ узкий

Ну тогда можно было их не показывать

Я правда так считаю.

+

ну я так понимаю, они хотели нескольких зайцев убить через декораторы

мне еще показалось что это некий выпад в сторону питонистов мол вот вам декораторы как у вас, переходите к нам

Там написано, что ожидают фидбек после презентации. Лучше свои предложения писать не в телеграм-чат, где они пропадут, а в тикеты.

Там просто нет хорошего примера, как плохо всё может быть

понял

Александр вот активно учавствует в обсуждениях и к нему прислушиваются. :)

Ну да, зачем делать маленькую обособленную фичу, если можно сделать обобщённую и решить сразу несколько проблем

Дык так и происходит сейчас, и выше уже обсудили, что раз в ропдмапе нет, то это всё, вероятно, нескоро появится.

а ссылки вот на issues не добавили на ютуб

Вроде и да, в ченджлоге вижу по сто фиксов на релиз, но до багов, от которых страдаю лично я, как-то не доходит)

потому что это не всегда хорошо

Не буду включать зануду в ответ, пожалуй)

Нехорошо - это накидывать много мелких несвязанных улучшений, каждое из которых немного, но усложняет язык. Фичи языка должны хорошо дополнять друг друга.

Щас тебе придут расскажут, что наллабилити -- маленький обособленный костыль, и надо было выразить это в системе типов обычным опшнлом :)

Это да, не помешали бы

давайте тогда монады завезём

зачем их завозить

у тебя есть задача мультиресиверов, а ты делаешь это через декораторы. Это, во-первых, неочевидно, во-вторых - некрасиво (ну серьёзно), в третьих - костыльно:)

Если одно идеально ложится на другое (более обобщённое), как это можно назвать костылём? with() и лямбды с ресивером - это тоже костыль?

> неочевидно Ровно до момента, когда оно в ход пойдёт. > некрасиво Субъективщина и тоже вопрос привычки, КМК > костыльно Тем более субъективщина.

ну насчет некрасиво соглашусь, выглядит больше как костыль, нежелели решение

неочевиндо - потому что кто там внутри что ещё будет декарировать и как, не ясно, а тебе НЕ НУЖНО лишнего в функции, если ты ожидаешь в ней два ресивера Некрасиво - потому что это получается как-то сбоку от основного ресивера и риторика мультиресивера, где все ресиверы одинаковые смещается в сторону мультиресивера с primary ресивером (имхо) (классы с primary constructor в пример, но там это было уместно) костыльно - потому что это НЕ аннотация, НЕ функция, НЕ объект, но пишется через @, с типом, но при этом без каких-либо скобочек, а в итоге получается всё равно как-то сбоку

Ну это ж не финальный вариант, фидбек собирают, вперёд :)

Так в кипе и было два варианта, упорядоченные и неупорядоченные. В текущем виде показали упорядоченные. Они, среди прочего, лучше ложатся на то, что есть уже сейчас, с экстеншнами, объявленными внутри классов.

а вот интересно, как часто нужны одинаково важные ресиверы, по сравнению с решением с primary ресивером чаще всего, доп ресивер нужен для контекста какого-то, а сама уже ф-ию всё же вызывается на каком-то интсансе чаще код будет такой: with(a) { b.foo()} чем такой with(a) { with(b) { foo() } } и тогда, решение с декоратором with выглядит намного логичнее

я согласен, что с этого ракурса всё ок, НО как декоратор это накладывает главную проблему всех этих apply/run/with - неизвестно, что у тебя в итоге получится в ресиверах и у чего конкретно ты будешь вызывать какой-либо метод

я конечно хз как для большинства, но почему-то под мультиресиверами я не подразумеваю никогда конструкцию реализуемую через with { with {} } просто чтобы получить два класса в контексе, эта задача то в общем то уже решена и хочется просто упростить запись я почему-то всегда думал что проблема именно в функциональном типе мультиресивера

Какие ваши доказательства Елизаров просил накидать им юзкейсов :)

эта задача то в общем то уже решена и хочется просто упростить запись - что имеешь в виду?

что with { with{}} можно написать уже сейчас

Именно

Проблема скорее в невозможности объявления функции, которая должна быть доступна только в контексте более одного ресивера (кроме member extensions)

только если это твой класс - тогда через member extension а если это View андроида, или ещё что?

ну вот да

а пример можно? не очень понимаю проблему

val (View, Int).dp get() = this * resources.displayMetrics.density

Пример со слайда: экстеншен для Float, который должен работать только в контексте View (класс из фреймворка)

классический пример, только его и вижу)

зачем что-то придумывать ?

Справедливости ради, это - новый синтаксис, конфликтующий с компонентами

не очень понтяон в таком коде, что такое this тогда?

this@Int*

ну то есть добавить его сложнее, чем написать декоратор:)

а как ты вью умножил на денсити?

а почему int если первым идет view? как это вычисляется?

эм with(view) View@ { with(int) Int@ { println(this@Int * resources ...) } }

да, если в этом виде мы понимаем что происходит, то выше код не очевиден просто

почему? запретить просто к this обращаться

прсото надо заставить маркировать то к чему обращаешься

Всё так. А в случае декораторов вроде хорошо понятно, что во что nested, и в каком порядке мог бы быть обход this-ов. И то по-моему шла речь, что unqualified this, вероятно, будет запрещён.

Кто мешает @with<Type1, Type2>. Нормальный синтаксис. Но надо смотреть, как оно ляжет, это да.

Отсутствие vararg generics