хотелось бы поддержать предыдущего комментатора в вопросе @akomiaginпожалуйста, покажите, как с помощью перечисленных вами инструментов тюнинга сетевого стека
(selective acks, window scaling, congestion control, tw recycle, syn cookies, размеры буферов и многое другое)
вы получаете наносекундные задержки хотя бы на локалхосте?
что такое "дипломированный специалист Cisco"? что такое CCNA, CCNP, CCIE и CCAr - понятно (только еще область надо указать). Причем, тест на CCNA способен сдать любой человек, который просто умеет читать.
что такое "дипломированный специалист Cisco" - вообще не понятно.
Мне неинтересно, что там происходит в kotlin, c#, go или каких-то других языках, или какими аргументами руководствовались те или иные люди, создавая эти языки.
очень зря. именно поэтому и появляются странные мысли об "ущербности" операторов. а если бы интересовался, как дизайнятся языки и какими доводами руководствуются их создатели, то таких странных мыслей бы не возникало.
приведи хотя бы один пример, когда switch будет уместен
приводил уже выше.
никаких аргументов, почему оператор switch плох ты не привел. один жалкий частный случай "некрасивого" использования switch не является аргументом против наличия оператора в языке.
не приводил. ни одного разумного аргумента. код со switch прекрасно тестируется и поддерживается. "поддерживаемость" и "тестируемость" определяются не операторами языка, а самим кодом.
утверждать, что switch влияет на тестируемость - это то же самое, что утверждать, что использование if влияет на тестируемость.
нет, просто я искренне никак не могу понять твои аргументы. Пока я вижу аргумент в стиле "в этом частном случае можно написать код без использования switch, поэтому оператор надо убрать из языка вообще".
это даже близко не аргумент. это просто частный случай реализации паттерна "стратегия", который можно делать на switch, но более "канонично" сделать через наследование или с помощью DI.
этот частный случай никакого отношения не имеет к наличию оператора в языке.
и нет, switch - это не "процедурное наследие". это утверждение в корне не верно. рекомендую почитать то, как дизайнили тот же котлин и почему там есть оператор when. причем, можно даже напрямую к главному дизайнеру обратиться с этим вопросом. даже на русском. вот просто написать в любой соцсети вопрос: "Андрей, скажи, зачем ты запихнул процедурное наследие в виде when в новенький мультипарадигменный язык?!" он даже, наверняка, аргументированно ответит. но, все же, рекомендую сначала почитать.
так.. оказывается не все случаи в мире покрываются спрингом и не везде у нас есть DI. это уже прогресс.
хотелось бы напомнить, что JDK - это открытая платформа и любой может сделать ее лучше. рекомендую предложить свой PR и вписать свое имя в историю развития JDK!
хотя, мне трудно сходу представить, как можно улучшить код, который скомпилируется в несколько ассемблерных инструкций. но буду искренне рад увидеть твои улучшения в JDK 25
или может тут тоже надо создать на хипе дополнительный Map, дополнительный массив, дополнительные списки под каждую ячейку массива, в те списки положить дополнительные объекты типа Node, в которые положить врапперы над int? И все это ради... ничего?
кажется, что дизайнеры JDK хорошо понимали, что делают, использовав тут switch на закрытом множестве )
оператор языка не может что-то нарушать или как-то влиять на мифический "code style". оператор switсh, или if-else не может нарушать open-close точно так же, как оператор "+" не может нарушать принцип подстановки Лисков.
можно ли нарушить open-close используя оператор switch? можно конечно! а еще его можно нарушить используя if-else. а еще можно вообще не используя операторы ветвления его нарушить.
похоже ты не чувствуешь разницы между дизайном языка и дизайном структуры классов, написанных на этом языке.
Давай так. Можешь привести хоть один пример кода, где я не смогу переписать switch на что-то более нормальное?
давай так. я могу переписать код, использующий оператор '%' так, чтобы этот оператор не использовался. Могу переписать так, чтобы вычитание не использовалось.
ясно. Россен не умеет в полиморфизм и не знает про DI.
тогда давайте посмотрим в исходник метода lengthOfMonth класса LocalDate, который выглядит так
public int lengthOfMonth() {
switch (month) {
case 2:
return (isLeapYear() ? 29 : 28);
case 4:
case 6:
case 9:
case 11:
return 30;
default:
return 31;
}
}
что есть ни что иное, как switch с паттерн-матчингом (если бы исходники спринга кто-нибудь решился переписать на яву версии больше 17) и чем вы наверняка пользуетесь в своих проектах на спринге а вы мне скажите, что авторы спринга "не умеют в полиморфизм" и не знают про solid
хотите я покажу использование break (label) в коде JDK? ) или использование switch тоже в коде JDK?
давайте еще раз попробую свою мысль озвучить: switch - это оператор языка. он не имеет никакого отношения к дизайну структуры классов. он присутствует во многих объектно-ориентированных языках. он есть в C#, Go, Kotlin, Rust и много где еще. вы беретесь утверждать, что понимаете ООП лучше, чем дизайнеры C#, Go, Kotlin или Rust, которые изначально создавались как ООП языки?
я не понимаю аргументов в стиле "switch нарушает open/close принцип". это нонсенс! оператор языка не может нарушать правила дизайна структуры классов!
я готов поверить, что вы встречались с кодом, где оператор switch использовался не правильно. но и кухонные ножи, знаете ли, бывает используют не по назначению. разве это повод запрещать кухонные ножи?
и еще мне хочется развить вашу мысль: предлагаю убрать "else if" в частности и "else" вообще, так как, во-первых, без них можно обойтись, а во-вторых, это "очевиднейший bad smell"(тм)
но у вас нет аргументов против, кроме "это очевиднейший bad smell". почему он "очевиднейший", кому "очевиднейший", почему это вообще "bad smell" - не понятно. но давайте попробуем так: switch в коде - это очевиднейший good taste. оппонируйте!
И правильно ли я понимаю, что в вашей системе вполне допускается одновременное выполнение одной и той же задачи несколькими инстансами (но без тайм-аут исключения доработает только 1 или 0 задач)? То есть, если выполнение задачи на одном инстансе вышло за таймаут, но исключение еще не было выброшено, то другой инстанс вполне может начать выполнять ту же самую задачу?
Можно сделать удобную реализацию, чтобы thread local timeout автоматически учитывался во всех клиентах и jdbcTemplate.
А как у вас это реализовано? Учесть таймаут из thread-local можно либо постоянно (в цикле) проверяя, не вышли ли мы за лимит, либо проверить, сколько выполнялся код после того, как он, собственно, выполнился. Но тогда получается, что задача будет выполнена, а потом выброшено исключение (так как выполнение вышло за лимит). То есть, есть высокая вероятность того, что одна и та же задача будет выполнена много-много раз, но ни разу успешно.
кажется, что это самая интересная часть реализации, которую вы почему-то пропустили. Если у яндекса найдутся силы и время, чтобы выделить ThreadLocalTimeout в библиотеку, которая бы легко интегрировалась с ThreadPoolExecutors и имела расширения для интеграции с наиболее часто используемыми http-clients, и spring-data-commons, то это был бы однозначно плюсик в "карму"!
direct byte buffer - это, скорее, "управляемый" байт-буфер, чем "прямой" байт-буфер
хотелось бы поддержать предыдущего комментатора в вопросе
@akomiaginпожалуйста, покажите, как с помощью перечисленных вами инструментов тюнинга сетевого стека
вы получаете наносекундные задержки хотя бы на локалхосте?
ну вот выйдет окончательно structured concurrency (aka: JEP 453) и будут те же корутины, только вид сбоку.
что такое "дипломированный специалист Cisco"?
что такое CCNA, CCNP, CCIE и CCAr - понятно (только еще область надо указать). Причем, тест на CCNA способен сдать любой человек, который просто умеет читать.
что такое "дипломированный специалист Cisco" - вообще не понятно.
очень зря. именно поэтому и появляются странные мысли об "ущербности" операторов. а если бы интересовался, как дизайнятся языки и какими доводами руководствуются их создатели, то таких странных мыслей бы не возникало.
приводил уже выше.
никаких аргументов, почему оператор switch плох ты не привел.
один жалкий частный случай "некрасивого" использования switch не является аргументом против наличия оператора в языке.
не приводил. ни одного разумного аргумента.
код со switch прекрасно тестируется и поддерживается.
"поддерживаемость" и "тестируемость" определяются не операторами языка, а самим кодом.
утверждать, что switch влияет на тестируемость - это то же самое, что утверждать, что использование if влияет на тестируемость.
нет, просто я искренне никак не могу понять твои аргументы. Пока я вижу аргумент в стиле "в этом частном случае можно написать код без использования switch, поэтому оператор надо убрать из языка вообще".
это даже близко не аргумент.
это просто частный случай реализации паттерна "стратегия", который можно делать на switch, но более "канонично" сделать через наследование или с помощью DI.
этот частный случай никакого отношения не имеет к наличию оператора в языке.
и нет, switch - это не "процедурное наследие". это утверждение в корне не верно.
рекомендую почитать то, как дизайнили тот же котлин и почему там есть оператор when.
причем, можно даже напрямую к главному дизайнеру обратиться с этим вопросом. даже на русском. вот просто написать в любой соцсети вопрос: "Андрей, скажи, зачем ты запихнул процедурное наследие в виде when в новенький мультипарадигменный язык?!"
он даже, наверняка, аргументированно ответит.
но, все же, рекомендую сначала почитать.
так.. оказывается не все случаи в мире покрываются спрингом и не везде у нас есть DI. это уже прогресс.
хотелось бы напомнить, что JDK - это открытая платформа и любой может сделать ее лучше. рекомендую предложить свой PR и вписать свое имя в историю развития JDK!
хотя, мне трудно сходу представить, как можно улучшить код, который скомпилируется в несколько ассемблерных инструкций.
но буду искренне рад увидеть твои улучшения в JDK 25
или может тут тоже надо создать на хипе дополнительный Map, дополнительный массив, дополнительные списки под каждую ячейку массива, в те списки положить дополнительные объекты типа Node, в которые положить врапперы над int? И все это ради... ничего?
кажется, что дизайнеры JDK хорошо понимали, что делают, использовав тут switch на закрытом множестве )
оператор языка не может что-то нарушать или как-то влиять на мифический "code style".
оператор switсh, или if-else не может нарушать open-close точно так же, как оператор "+" не может нарушать принцип подстановки Лисков.
можно ли нарушить open-close используя оператор switch? можно конечно! а еще его можно нарушить используя if-else.
а еще можно вообще не используя операторы ветвления его нарушить.
похоже ты не чувствуешь разницы между дизайном языка и дизайном структуры классов, написанных на этом языке.
давай так. я могу переписать код, использующий оператор '%' так, чтобы этот оператор не использовался.
Могу переписать так, чтобы вычитание не использовалось.
Это повод убирать эти операторы из языка?
ясно. Россен не умеет в полиморфизм и не знает про DI.
тогда давайте посмотрим в исходник метода lengthOfMonth класса LocalDate, который выглядит так
авторы JDK тоже не умеют в полиморфизм?
еще давайте я покажу это
https://github.com/spring-projects/spring-framework/blob/1af64802174c0122b59a2178f17f8f1d2b4cbcd4/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/ResponseEntityExceptionHandler.java#L143
что есть ни что иное, как switch с паттерн-матчингом (если бы исходники спринга кто-нибудь решился переписать на яву версии больше 17) и чем вы наверняка пользуетесь в своих проектах на спринге
а вы мне скажите, что авторы спринга "не умеют в полиморфизм" и не знают про solid
хотите я покажу использование break (label) в коде JDK? )
или использование switch тоже в коде JDK?
давайте еще раз попробую свою мысль озвучить: switch - это оператор языка.
он не имеет никакого отношения к дизайну структуры классов.
он присутствует во многих объектно-ориентированных языках.
он есть в C#, Go, Kotlin, Rust и много где еще.
вы беретесь утверждать, что понимаете ООП лучше, чем дизайнеры C#, Go, Kotlin или Rust, которые изначально создавались как ООП языки?
я не понимаю аргументов в стиле "switch нарушает open/close принцип".
это нонсенс!
оператор языка не может нарушать правила дизайна структуры классов!
я готов поверить, что вы встречались с кодом, где оператор switch использовался не правильно.
но и кухонные ножи, знаете ли, бывает используют не по назначению.
разве это повод запрещать кухонные ножи?
пока вижу лишь голословные утверждения.
нет, не нарушает.
нет, не усложняет.
все, что вы описали - это вопросы дизайна структуры классов, которые не имеют отношения к оператору языка.
можно ли использовать оператор не корректно и нарушить общепринятые принципы дизайна?
да, можно.
вот только, при чем тут сам оператор языка?
и еще мне хочется развить вашу мысль: предлагаю убрать "else if" в частности и "else" вообще, так как, во-первых, без них можно обойтись, а во-вторых, это "очевиднейший bad smell"(тм)
но у вас нет аргументов против, кроме "это очевиднейший bad smell". почему он "очевиднейший", кому "очевиднейший", почему это вообще "bad smell" - не понятно.
но давайте попробуем так: switch в коде - это очевиднейший good taste.
оппонируйте!
И правильно ли я понимаю, что в вашей системе вполне допускается одновременное выполнение одной и той же задачи несколькими инстансами (но без тайм-аут исключения доработает только 1 или 0 задач)?
То есть, если выполнение задачи на одном инстансе вышло за таймаут, но исключение еще не было выброшено, то другой инстанс вполне может начать выполнять ту же самую задачу?
А как у вас это реализовано? Учесть таймаут из thread-local можно либо постоянно (в цикле) проверяя, не вышли ли мы за лимит, либо проверить, сколько выполнялся код после того, как он, собственно, выполнился. Но тогда получается, что задача будет выполнена, а потом выброшено исключение (так как выполнение вышло за лимит). То есть, есть высокая вероятность того, что одна и та же задача будет выполнена много-много раз, но ни разу успешно.
кажется, что это самая интересная часть реализации, которую вы почему-то пропустили. Если у яндекса найдутся силы и время, чтобы выделить
ThreadLocalTimeoutв библиотеку, которая бы легко интегрировалась с ThreadPoolExecutors и имела расширения для интеграции с наиболее часто используемыми http-clients, и spring-data-commons, то это был бы однозначно плюсик в "карму"!