@angmarr в питере никто не заявлялся организовывать

Позор. Родина Котлина же, и так поступить

Кстати надо будет попробовать

я думал ты пробовал

я думал ты пробовал

Да попробовал, он последовательно выполняет таски на своем екзекьютере из [кол-во ядер - 1] тредов. Те на 4 ядерном проце этот пример (100k sleep) займет >9 часов. Никакой магии, как Бреслав и говорил (в том же C# await Task.Delay(...) так же работает).

Кстати для delay реально используется lazy-синглтон ScheduledExecutorService (и синглтон сделан в java стиле)

@angmarr кстати был же ивент в Питере, я вспомнила. А какая была проблема с ним?

@angmarr кстати был же ивент в Питере, я вспомнила. А какая была проблема с ним?

Сегодня? Если ты про тот что был неделю/две назад в оффисе JB то с ним все ОК.

Да

Сегодня

Сегодня

Ок, есть тут Питерские, кто был на нем сегодня?

а кстати

фичи за которые голосовать можно было

о

?

Ну как у вас проголосовали?

за Лукашенко)

за Лукашенко)

Все верно, в нашем голосовании победил Лукашенко)))

Collection Literals крутые, прям как в жс)

[x.name for x in employees if x.division == Production] хардкор!

1. Value classes (14) 2. Truly immutable data (12) 3. Unsigned arithmetic (7) 4. SAM Conversions for Kotlin interfaces (7)

Subject variable in when - неплохо бы

но щас можно через let сделать

мне кажется большую часть из этого списка реализуют в любом случае

Кто за что голосовал? Я за 1. SAM 2. invokedynamic 3. prive functions tests

я бы некоторые фичи банил

например, private functions tests - не ооп-шно

Я запятые бы забанил

Нужно было еще красные стикеры давать

это да. надо бы

@meilalina в следующий раз еще дизлайки нужно делать)

Кто за что голосовал? Я за 1. SAM 2. invokedynamic 3. prive functions tests

Есть вообще идеи как будет работать 3? (вообще ничего интересного, но usigned арифметики не хватает, после C#)

опциональные запятые - как раз норм фича. синтаксический сахар, который ничего не ломает

например, private functions tests - не ооп-шно

да это вообще даже звучит странно

Кто за что голосовал? Я за 1. SAM 2. invokedynamic 3. prive functions tests

Зачем SAM? Ради интероперабельности с Котлинскими интерфейсами придётся оборачивать анонимные классы в другие анонимные классы.

Жирный красный кружочек на sam от меня)

Вообще я голосвал не за новые жирные фичи, а за добавление удобства работы. Большой уход от java как с unsigned или value types не думаю что хорошо

тестировать приватные функции удобно - можно через такой же тулинг как open плагин

просто и удобно.

поддержка SAM я до сих пор не понимаю почему не так.

invokedynamic – мелочь, но шаг вперёд

Value классы - давайте подождём как там будет в java, не вижу причин не ждать

Это немного ортогонально value types в джава)

И зачем тогда?

мне надо глянуть как там в java планирует сделать, забыл совсем

насчёт truly immutable – поясните мне вот профит? Я рад что будут коллекции имутабельные, но зачем эта фича?

Subject variable in when - это приятная маленькая мелочь, буду рад ей

статик функции не хотелось бы видеть

насчёт truly immutable – поясните мне вот профит? Я рад что будут коллекции имутабельные, но зачем эта фича?

Чтобы было понятно, что объекты этого класса можно спокойно использовать в параллельном программировании.

статик функции не хотелось бы видеть

++, non-idiomatic

Чтобы было понятно, что объекты этого класса можно спокойно использовать в параллельном программировании.

1. новое спорное клчевое слово 2. Как это контролироваться будет 3. Что мешает тебе сделать имутабельный класс самому, если это удобно

++, non-idiomatic

Тем более они уже есть, а это по сути сахар для удобства

И зачем тогда?

затем же зачем тайп классы

"создаешь" класс, при этом никакого оверхеда

типа да, но... С другой стороны чисто ради лучшего experiance java->kotlin

статик функции не хотелось бы видеть

отстой да

optional commas -> язабан

И вот не определился насчёт литералов в статиккомпайл языках. Вы что думаете?

short enums, multicatch - норм

1. новое спорное клчевое слово 2. Как это контролироваться будет 3. Что мешает тебе сделать имутабельный класс самому, если это удобно

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

short enums, multicatch - норм

госовал за первый)

госовал за первый)

так это, статик импорт.. не?

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

вово, и пошла жара с аннотациями. Аннотации не ооп

ERROR: S client not available

так это, статик импорт.. не?

Не совсем. Логично разрешить короткий enum только там, где when на объекте соответствующего типа. By the way, в switch в Java можно писать *только* короткий enum (но switch менее гибкий, чем when, это да).

+1

вово, и пошла жара с аннотациями. Аннотации не ооп

Ну, лямбды тоже не особо ООП. Kotlin — не сферический правильный язык в вакууме, а смесь тех парадигм, которые больше всего нужны для решения реальных задач.

вово, и пошла жара с аннотациями. Аннотации не ооп

Немного нубский вопрос, но почему аннотации не ооп?

неочевидно (с)

вообще с ООП путаница некоторая есть, как мне кажется

люди аннотации считают магией

кто хочет декораторов? ?

есть же делегаты для этого, не?

Ну, делегатов хватит всем)

в традиционных языках - java, c++, c# ООП - это наследование, инкапсуляция. полиморфизм. Но сам создатель ООП, Алан Кей делал упор на систему сообщений, то что-то ближе к Эрлангу и Акка

Немного нубский вопрос, но почему аннотации не ооп?

http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html

http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html

я б не ссылался на этот источник)

есть же делегаты для этого, не?

не, ну это такие аннотации, которые статически привязаны к оборачивающему методу

чтобы кликнул на аннотацию, и перешел к коду

такой продвинутый АОП

http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html

у него, насколько я помню, свой собственный "правильный" ООП?

http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html

нууу, сомнительно. ООП не сводится к инкапсуляции, это вообще больше про solid.

чтобы кликнул на аннотацию, и перешел к коду

так это уже больше вопрос к тулингу

нууу, сомнительно. ООП не сводится к инкапсуляции, это вообще больше про solid.

solid сводится к процедуркам на стероидах(читать как типах)

Ну то как сейчас работают @Async например в спринге тулинг особо не поможет

ну типо для спринга сделать можно, но в общем случае - нет

http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html

Мнение Егора Бугаенко, безусловно, интересно и заслуживает внимания. И в некоторых случаях я очень плюсую ему. Кроме того, у него есть отличные статьи "за жизнь" — про собеседования в гугле, про посредников (майонез) и так далее. Но, как всегда, нужно понимать что технология или шаблон проектирования в определённом контексте хорош не тем, в какой степени он ООП, а тем, насколько он решает поставленную задачу.

Всё так

Backend разработчики, кто как документирует свой код (своё API)? Spring boot, jakson для отображения json<->class под капотом. Использую KDoc Syntax для того чтобы документировать pojo классы (data class) и контроллеры. Хотелось бы генерировать документацию, в виде json. То есть чтобы клиенты для этого API видели примеры: - какие json можно посылать POST запросами - какие Json приходят в ответ на GET запрос. Сейчас это ручками в основном делается, но хочется автоматизировать, хоть на половину. Более конкретно, например: rest controller - https://gist.github.com/anonymous/4e0d1e58a5f467764b970c7bbc0e5022 а на выходе хотелось бы получить примеры json к этому API. типа GET возвращает ``` [ { //поля Item } ] ``` здесь приводится сравнение некоторых тулз. https://opencredo.com/rest-api-tooling-review/ Но мне интересно, кто как и что наладил в своей работе?

а зачем? для rest берешь swagger, а остальной код это твой код. ты ж не библиотеки и sdk пишешь

у нас swagger для этого узается.

и модели данных видно. и прям через него реалные реквести поранить можно.

Swagger — это же тонкая обёртка над БД? А если бэк выполняет реальную работу?

Swagger это штука для документации API

оно само ничего не делает