вот он проглотит любой вызов метода

и find("guga", "vloger")

и find("guga")

и вызовет именно этот метод public User find(String... args)

как 3 точки в java называются?

хз

как 3 точки в java называются?

varargs

я ими никогда не пользуюсь

varar feature

аргументы переменной длинны

Пользоваться ими плохой тон или из-за личных предпочтений?

я ими никогда не пользуюсь

на русском

да просто никогда не нужно было

типа

я всегда делаю разные классы для всего

телефон был бы у меня не строкой, а отдельный классом phone

может имя было бы просто строкой

и то не уверен

Пользоваться ими плохой тон или из-за личных предпочтений?

Это вкусовщина, так как туда можно передать массив.

ну да

тебе никто не мешает правда сделать find(String[] args)

и будет так же

А зачем тогда varargs, если можно через String[]?

ну

не так же

типа вот это ты делать не сможешь

и find("guga", "vloger")

и find("guga")

сможешь делать find(new String[] {"guga", "vloger"})

А зачем тогда varargs, если можно через String[]?

Писать удобнее.

А перебирать все комбинации полей поиска - норм?

Builder pattern

Блин, люди! Почему в джаве нет значений по-умолчанию?? Какая причина так не делать была?

Блин, люди! Почему в джаве нет значений по-умолчанию?? Какая причина так не делать была?

Потому что сложно

Потому что сложно

А что сложного?

Делать отдельный код для значений по умолчанию

Не забывай там одни указатели

А при значении по умолчанию значение еще надо создать где то

Не забывай там одни указатели

*минутка занудства* то есть ссылки

Pointer все таки указатель

А при значении по умолчанию значение еще надо создать где то

А при явном вызове нигде не надо создавать значение?

Почему нельзя было сделать сахаром? Чтобы компилятор сам делал вызовы конструктора с подставленными туда необязательными полями?

Надо, только это делает jvm при явном указании на то

Например, чтобы new Clazz(foo) компилятор воспринимал как new Clazz(foo, default_value). Это же сахар и на байт-код не влияет никак. А язык становится гибче.

Например, чтобы new Clazz(foo) компилятор воспринимал как new Clazz(foo, default_value). Это же сахар и на байт-код не влияет никак. А язык становится гибче.

Сложно. Основная причина появления джавы именно попытка уйти от сложности си.

Сложно. Основная причина появления джавы именно попытка уйти от сложности си.

Это гораздо проще, чем понять что будет во время такого кода: try { return foo; } finally { do_smth(); }

Ну смысл прыгать по разным структурам языка.

+ сложности в значениях по умолчанию нет никакой. Основная сложность в низкоуровневой работе с памятью. В функциях со значениями по умолчанию сложности нет.

Тебе что больше нравится Document doc = Jsoup.parse(file, Charset.DefaultEncoding(), "/"); Или же Document doc = Jsoup.parse(file); ? Вот мне нравится второй вариант. И он очевидно что делает. В первом случае аргументы тупо избыточны.

Мне нравится создать jsoup с нужными полями, инжекнуть в сервис и норм. И использовать второй вариант записи.

Мне нравится создать jsoup с нужными полями, инжекнуть в сервис и норм. И использовать второй вариант записи.

Да, но почему приходится так извращаться, чтобы сделать код проще?

офтопик

потому что код не только писать, но и читать потом надо. И поддерживать. А имплиситы потом аукнутся после того, как ты через неделю посмотришь на код и не поймёшь, что вообще происходит.

потому что код не только писать, но и читать потом надо. И поддерживать. А имплиситы потом аукнутся после того, как ты через неделю посмотришь на код и не поймёшь, что вообще происходит.

Да? Можно пример кода, который будет не понятен через время, но понятен при написании. Выше написанный код я и через год смогу прочитать.

Ты его и приводил. Document doc = Jsoup.parse(file); От того, что ты коротко напишешь, разбираться потом не проще будет.

Ты его и приводил. Document doc = Jsoup.parse(file); От того, что ты коротко напишешь, разбираться потом не проще будет.

Что не понятного в этом куске кода?

Это сейчас всё понятно, вернись к нему через неделю, увидишь.

Это сейчас всё понятно, вернись к нему через неделю, увидишь.

Я враппер вокруг Jsoup делал 2 месяца назад. Пришёл к такому варианту. Читается всё отлично.

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

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

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

Почему? Я не понимаю этого. Давайте я приведу пример очень популярной библиотеки: FileUtils.writeStringToFile(file.toFile(), document.toString(), Charset.defaultCharset(), false); Супер понятно, что я хотел сделать, правда? Я больше скажу. Они задепрекейтили метод с двумя аргументами, так как есть вот такой всё умеющий делать монстр. Зато супер читаемо всё, правда?

можно юзать аннотации для дефолт значений, но сигнатуру метода это не изменит, поэтому все равно уродство

Для своих нужд ты напишешь обёртку, функциональность, предоставляемая обёрткой, будет инкапсулирована внурти так, что если для тебя будет условно "не важно" с какими аргументами будет вызываться writeStringToFile . Используя эту обёртку, ты сможешь решать свои задачи, не заботясь о деталях. А если надо будет, то пойдёшь и посмотришь внутрь и увидишь. Но скрывать по умолчанию от любого, читающего код было бы неверно и делать неявными параметры, которые ты считаешь неважными.

Для своих нужд ты напишешь обёртку, функциональность, предоставляемая обёрткой, будет инкапсулирована внурти так, что если для тебя будет условно "не важно" с какими аргументами будет вызываться writeStringToFile . Используя эту обёртку, ты сможешь решать свои задачи, не заботясь о деталях. А если надо будет, то пойдёшь и посмотришь внутрь и увидишь. Но скрывать по умолчанию от любого, читающего код было бы неверно и делать неявными параметры, которые ты считаешь неважными.

А почему не сделают супер-метод тогда? Зачем нужны разные методы, если всё равно под каждый чих нужно писать обёртку?

Мне кажется, значения по умолчанию - это тема для оффтопа

Мне кажется, значения по умолчанию - это тема для оффтопа

Возможно, но я не вижу вреда, которые они несут. Всё равно Java код без IDE не пишут, а там уже подсказки будут. А значения по умолчанию значительно улучшают читаемость.

Возможно, но я не вижу вреда, которые они несут. Всё равно Java код без IDE не пишут, а там уже подсказки будут. А значения по умолчанию значительно улучшают читаемость.

Оффтоп

ERROR: S client not available

А в месте с дефолтными значениями пришлось бы еще и именованные параметры сделать.

А в месте с дефолтными значениями пришлось бы еще и именованные параметры сделать.

Зачем?

В реализации дефолтные значений, значение которое задано можно опустить, значить компилятор должен знать не только его позицию

В реализации дефолтные значений, значение которое задано можно опустить, значить компилятор должен знать не только его позицию

Эм?

Прости, но я не понял, что ты написал.

Прости, но я не понял, что ты написал.

параметр с дефолтным значением может стоять между другими

допустим у тебя есть метод foo(int a, int b = 2, int c), ты его можешь вызнать как foo(1, 2)

допустим у тебя есть метод foo(int a, int b = 2, int c), ты его можешь вызнать как foo(1, 2)

Вот такие вещи я бы запретил.

lol

а какой тогда профит от дефолтных значений?

чем тебя не устроила цепочка методов foo(int a, int c){ foo(int a, 2, int c) }

чем тебя не устроила цепочка методов foo(int a, int c){ foo(int a, 2, int c) }

так и делают частенько

но выглядит не очень, когда куча такой лапши вложенной

оберточная наркомания я это называю

По моему с пивасом потянет

алкоголь и кодинг не совместимы

алкоголь и кодинг не совместимы

главное в мастер не мёрджить, а так всё отлично идёт

на новый год 2015 мы с другом 2 часа пытались написать хеллоу ворлд

Но, если честно, я не понимаю, почему в жабу не добавят именованных параметров и дефолтных значений. Это же изменения на уровне javac

не все так просто, очевидно

иначе бы сделали

ну как бы в скале это есть

не все так просто, очевидно

Да, я согласен. Но я не понимаю почему так.

в котлине тоже

https://kotlinlang.org/docs/reference/functions.html#named-arguments

там есть активисты

которые за все новое

но не все утверждают

Симпотично выглядит. Беру своё мнение назад. Именованые параметры неплохи.

значит что-то это ломает и будет стоить дорого

значит что-то это ломает и будет стоить дорого

Сейчас внедрение - это проблема, так как код может сломаться. Я понимаю, почему это не внедряют. Обратная совместимость - это же главное)

А что это ломает? о_О