но вы же просто заменили catch на addWrapper(ExceptionHandler.DEFAULT) это не снизило когнитивную нагрузку при чтении это ее повысило вместо привычного, описанного во всех учебниках синтаксиса, надо осознавать ваш доморощенный
кстати, покажите пожалуйста пример с вашим аналогом finally (post-processor, который отрабатывает всегда, вне зависимости от того, было ли выброшено исключение в процессе прохода по вашему пайплайну)
я из мира радиоэлектроники в программирование пришел. математик из меня - никакой, но я тоже использую операцию "+", когда мне нужно сложить 2 числа, а не сажусь паять сумматор
хотелось бы поддержать предыдущего комментатора в вопросе @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 использовался не правильно. но и кухонные ножи, знаете ли, бывает используют не по назначению. разве это повод запрещать кухонные ножи?
Это очень недооцененная статья.
Спасибо, что опубликовали!
но вы же просто заменили catch на addWrapper(ExceptionHandler.DEFAULT)
это не снизило когнитивную нагрузку при чтении
это ее повысило
вместо привычного, описанного во всех учебниках синтаксиса, надо осознавать ваш доморощенный
кстати, покажите пожалуйста пример с вашим аналогом finally (post-processor, который отрабатывает всегда, вне зависимости от того, было ли выброшено исключение в процессе прохода по вашему пайплайну)
Смысл этих аннотаций - отлавливать null-refs во время компиляции (сборки).
Валидаторы тут совершенно ни при чем.
я из мира радиоэлектроники в программирование пришел. математик из меня - никакой, но я тоже использую операцию "+", когда мне нужно сложить 2 числа, а не сажусь паять сумматор
Зашел написать аналогичный комментарий, а он уже есть.
Спасибо!
Вся статья - еще одно плохое объяснение solid.
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 использовался не правильно.
но и кухонные ножи, знаете ли, бывает используют не по назначению.
разве это повод запрещать кухонные ножи?
пока вижу лишь голословные утверждения.
нет, не нарушает.
нет, не усложняет.
все, что вы описали - это вопросы дизайна структуры классов, которые не имеют отношения к оператору языка.
можно ли использовать оператор не корректно и нарушить общепринятые принципы дизайна?
да, можно.
вот только, при чем тут сам оператор языка?