Я ж правильно понимаю, что оно семантически эквива...
# russian
s
Я ж правильно понимаю, что оно семантически эквивалентно: named@for(a in arr) { ... continue@named ... } и arr.forEach lam@{ a-> ... return @lam ... } ?
e
Да
s
Ок, будем ковырять, спасибо.
e
А чтобы имитировать break, нужно завести именованную лямбду вокруг цикла.
s
Эти замечания кстати наталкивают на буквальную реализацию в компиляторе, генерить неявные лямбды в соответствующих местах, заменять break/continue на соотв вызовы, а оптимизатор уже выоптимизит неиспользуемое.
e
Да реализовать это может и не так сложно. Тут же всё вопрос в приоритетах и вообще юзкейсах. Экзотическая это весьма нужда
Если есть интересные юзкейсы — добавляйте в issue.
s
Ну вот я писал на жабе много кода, и эти случаи, использование continue с выходом из вложенных synchronized, они у меня повсюду, потому что одним словом как бы делается сразу много, и keywords с "сильной" фактической нагрузкой делают программу на жабе короче, что и хорошо, и естественно стремится быть использованным чаще. Вот такой вот кейс.
e
Вложенные synchronized это очень плохой smell. Увеличение абстрации (extract method/function refactoring и т.п.) спасет отца русской демократии.
o
Вложенные synchronized вытащенные в функции усложняют слежение за порядком захвата блокировок…
s
Усложняет. А что облегчает слежение за порядком блокировок вообще? Только бдительность.
Вот у меня есть мелкие объекты, которые входят в состав многих коротких мапов (индексов). На входе код объекта. Я лочусь на мапе, и потом на объекте, когда там его найду, потом его мутирую там или что еще. Такой вот паттерн доступа. Если зарефакторить, то вместо вложенного continue@ придется мудрить возвращать что-то еще дополнительно, n'est-ce pas?
Ага, это был ответ Ильи Роману, а я не распарсил
o
Ну можно использовать более другие структуры данных, которые подходят для конкурентной работы.
s
ConcurrentHashMap например, но там действие происходит в лямбде, откуда break точно не сделаешь.