i
Привет, вопрос, в как типизировать параметр функции, если я там жду object, который наследует определенный класс ?
Size: a a a
2020 May 21
AN
Привет, вопрос, в как типизировать параметр функции, если я там жду object, который наследует определенный класс ?
как класс
i
действительно, спасибо)
VS
Channelы не умеют в приоритеты, к сожалению
1) А чем плохо держать ту же самую PriorityBlockingQueue внутри корутины?
2) Чем плохо создавать корутину для «отложенной отправки»? Грубо говоря, если не получилось, то создаём корутину, которая делает delay + отправку.
2) Чем плохо создавать корутину для «отложенной отправки»? Грубо говоря, если не получилось, то создаём корутину, которая делает delay + отправку.
VP
1) А чем плохо держать ту же самую PriorityBlockingQueue внутри корутины?
2) Чем плохо создавать корутину для «отложенной отправки»? Грубо говоря, если не получилось, то создаём корутину, которая делает delay + отправку.
2) Чем плохо создавать корутину для «отложенной отправки»? Грубо говоря, если не получилось, то создаём корутину, которая делает delay + отправку.
1- тем, что каждая из них заблочит тред?
VS
1- тем, что каждая из них заблочит тред?
Какой из?
Зачем блокироваться-то?
Можно же сделать peek, посмотреть «сколько времени до ближайшего события» и жахнуть delay(…) корутинный.
Зачем блокироваться-то?
Можно же сделать peek, посмотреть «сколько времени до ближайшего события» и жахнуть delay(…) корутинный.
VP
Какой из?
Зачем блокироваться-то?
Можно же сделать peek, посмотреть «сколько времени до ближайшего события» и жахнуть delay(…) корутинный.
Зачем блокироваться-то?
Можно же сделать peek, посмотреть «сколько времени до ближайшего события» и жахнуть delay(…) корутинный.
Так это уже не похоже на "взять готовую очередь с приоритетом", это на уровне того, что я предложил с мьютексом
VP
То есть аналога блокирующей, но не блокирующей тред, очереди с приоритетом нет, и её надо делать самому
IK
1) Насколько я понимаю тем, что блокировка будет распространяться на поток, а не на корутину.
2) Прикольный вариант, но не совсем понятно, как упорядочивать. Потому что нужно учитывать, что новые сообщения для того же канала должны будут выполниться после старого. Будут костыли
2) Прикольный вариант, но не совсем понятно, как упорядочивать. Потому что нужно учитывать, что новые сообщения для того же канала должны будут выполниться после старого. Будут костыли
IK
Какой из?
Зачем блокироваться-то?
Можно же сделать peek, посмотреть «сколько времени до ближайшего события» и жахнуть delay(…) корутинный.
Зачем блокироваться-то?
Можно же сделать peek, посмотреть «сколько времени до ближайшего события» и жахнуть delay(…) корутинный.
Вот это кстати классная идея, и это мне нравится больше всего пока что. Но насколько я понимаю, если речь идет о корутинах – в таком случае мьютекс все-равно понадобится.
VP
Забавно, если не указать конкретный тип у переменной то уже ругается идея, но код компилится. А если указать параметер в лямде то наоборот.
Думаю это мавен плагин
Думаю это мавен плагин
Старый type inference в этом месте многое не умел (в IDE по умолчанию включен новый, поэтому там ошибок не было).
По поводу ругательств Идеи (т. е. нового инференса) при опускании типа параметра лямбды: мы совсем недавно улучшили вывод параметров лямбд, так что скорее всего Ваш пример заработает (это попадет в 1.4-M3, либо можно уже сейчас взять dev-билд и поиграться). Вот в этом коммите в testData можно глянуть некоторые поддержанные кейсы: https://github.com/JetBrains/kotlin/commit/260683c20ef7ea5e51a11ecb8dae7c64793c8720
По поводу ругательств Идеи (т. е. нового инференса) при опускании типа параметра лямбды: мы совсем недавно улучшили вывод параметров лямбд, так что скорее всего Ваш пример заработает (это попадет в 1.4-M3, либо можно уже сейчас взять dev-билд и поиграться). Вот в этом коммите в testData можно глянуть некоторые поддержанные кейсы: https://github.com/JetBrains/kotlin/commit/260683c20ef7ea5e51a11ecb8dae7c64793c8720
BP
Старый type inference в этом месте многое не умел (в IDE по умолчанию включен новый, поэтому там ошибок не было).
По поводу ругательств Идеи (т. е. нового инференса) при опускании типа параметра лямбды: мы совсем недавно улучшили вывод параметров лямбд, так что скорее всего Ваш пример заработает (это попадет в 1.4-M3, либо можно уже сейчас взять dev-билд и поиграться). Вот в этом коммите в testData можно глянуть некоторые поддержанные кейсы: https://github.com/JetBrains/kotlin/commit/260683c20ef7ea5e51a11ecb8dae7c64793c8720
По поводу ругательств Идеи (т. е. нового инференса) при опускании типа параметра лямбды: мы совсем недавно улучшили вывод параметров лямбд, так что скорее всего Ваш пример заработает (это попадет в 1.4-M3, либо можно уже сейчас взять dev-билд и поиграться). Вот в этом коммите в testData можно глянуть некоторые поддержанные кейсы: https://github.com/JetBrains/kotlin/commit/260683c20ef7ea5e51a11ecb8dae7c64793c8720
спасибо жуду наблюдать
AN
В сериализации 1.4-M2 наконец завозят градл модули
VS
В сериализации 1.4-M2 наконец завозят градл модули
Это что значит?
AN
Это что значит?
Это значит, что можно будет подключать все либы по kotlinx-serialization без суффикса. В том числе в мультиплатформе
AM
В сериализации 1.4-M2 наконец завозят градл модули
В смысле модули просто из -native переехали в безсуфиксный артефакт?
AM
Раньше ж в -native лежало всё, включая жвм с жсом, ЕМНИП
AN
чьерт, я тут не админ
IO
чьерт, я тут не админ
?