Зачем нужен var в Java?

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

В этом аргументе нет слова «читать»

Не решили. Это JEP, который даже ещё не приняли

Вывод типов, даже в Java, может вывести довольно странные типы, которые не так просто записать руками. Еще нужно не забывать про то, что возвращаемые значения методов ковариантны, так что реальный тип который возвращает вызов может отличаться от того что об этом думает разработчик. Для таких случаев var полезен.

Ну и не нужно забывать то что код будет более короткий и читаемый.

в Java решили ввести ключевое слово var

Если это не сломает типизацию, то можно.

хотя бы на хабре

Стоит ли слушать сборище напыщенных погромистов, которые почему-то считают что им всё и все должны? А аргументы уровня «моя IDE » просто поражают. Они считают что разработчики обожрались белены, и не состоянии учитывать очевидных вещей. Экосистема, [censored]. Задрали уже обсасывать голые кости. Сказали будет — значит будет. Не нравится — не используй. Хочешь чтобы никто не юзал в команде — добавляй еще одно правило.

Может, хотя бы здесь кто-то всё-таки сможет привести подобный пример?

Иногда и часто тип переменной очевиден
this
/thread

по сабжу: просто предположение, с жабой сильно не знаком, но может для типа-макросов-шаблонов, не?

Очевидно, авторы этой идеи целый день пишут код (именно пишут, а не проектируют), и у них устают пальчики. Поэтому они уменьшают количество набираемых символом.

В том же. где и auto в c++11. Везде короче.

читать --- это дело привычки, равно как и писать.

при наличии привычки на скале приятнее :)

ты хоть покажи что ты называет «нечитабельностью», не def main же тебе не нравится.

Биореактор еще не появлялся с анализом зарплат?

А аргументы уровня «моя IDE » просто поражают.

За что боролись.

Дели дальше. Мне нужны грамотные коллеги, а школота которой задачу на 15 минут нужно объяснять 2 часа.

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

Годно, плюсовое auto внесло в язык немного гибкости.

Не нравится — не используй.

Мне не нравится, но вот оно будет использоваться в куче сторонних библиотек. И тут никакие корпоративные правила это не исправят. Не будут разработчики слушать пользователей. Как вот такой вот сторонний говнокод анализировать. Доку пока народ не научился писать нормальную, только исходники порой объясняют всё что не понятно.

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

И как этому способствует «var»? А никак. Проутюжить пол проекта чтобы таки узнать чем оно станет - ах какое упрощение процесса рефакторинга.

var ... Проутюжить пол проекта

если у тебя проект сотоит из одной функции то да, это пол проекта, но тогда не вижу проблем.... или стоп у тебя одна функция в миллион строк?

Не будут разработчики слушать пользователей. Как вот такой вот сторонний говнокод анализировать.

Очевидно, не использовать говно-библиотеки. Выше вертухай уже сказал — есть кучи вариантов, когда тип очевиден даже дебилу. А тот, кто будет юзать var там, где тип будет не очевиден, очевидно, сам дебил (простите мой каламбур). Живой показатель — автор статьи. Дальше его начально примера я даже не читал, ибо блеванул.

Супер, я буквально на 20 постов выше написал

есть наркоманы-старперы, которые до сих пор возмущаются, что джава куда-то слишком спешит и вот на 6-ке было всем уютно

спасибо за пруф!

За что боролись.

Да меня поразила не сама суть аргумента, а факт его наличия. Строго говоря там все аргументы можно выкинуть на помойку. Вместе со статьей.

Как будто тебя заставляют так писать.

Не не, статья нужная она автору дала инвайт на хабр, если кто еще не догадался.

Ты работаешь один?

Слизали с auto у крестов, kik.

Лол. Я и не знал, что у жапки есть «порог вхождения». Вся студентота на ней с первого семестра херачит говнокод.

она автору дала инвайт на хабр

Ааа, ну тогда респект пацану, он поимел хабр.

Очевидно, не использовать говно-библиотеки.

Очевидно на практике не получается «не использовать».

Студентота с первого семестра говнокод может херачить на чем угодно, в том числе на той же Scala/Cpp.
Только как естественный процесс накопления выразительности связан с освоением языка в принципе?

А кресты у кого слизали?

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

А еще, на практике я не разу не «анализировал» код библиотеки.

Значит мало практики.

У javascript, же

Скажите, зачем? Я использую библиотеку как черный ящик, и только по документации. Это нормальная практика. Если нужно что-то прикрутить — я должен делать это посредством самой библиотеки, а не за счет изменения её кода. Если библиотека это не позволяет — меняем на другую. Если наши запросы слишком извращенные — пишем свое решение. Или вы под анализированием подразумеваете просто изучение чужого кода? Тогда да, var может снизить читаемость, но только если его не правильно применять, тогда я бы и не стал читать такой код. Говнокод я могу и на соответствующем ресурсе почитать.

Скажите, зачем? Я использую библиотеку как черный ящик, и только по документации.

пример из жизни:

как узнать почему jdbc драйвер postgres тормозит?

ты используешь в этом случае другой драйвер или пишешь свой?

ответ: при получении метаданных резалтсета он отправлял на сервер +1 запрос на каждый столбец, потому что при некоторых условиях внутренний кеш не срабатывал

ответ: при получении метаданных резалтсета он отправлял на сервер +1 запрос на каждый столбец, потому что при некоторых условиях внутренний кеш не срабатывал

Об этом нет ни слова в документации?

о багах которые ты находишь никто кроме тебя не напишет

[joke] У plain C [/joke]

Скажите, зачем? Я использую библиотеку как черный ящик, и только по документации.

во многих случаях доки и код не совпадают, например

юмор: очевидно затем, чтобы узнать что нужно писать вместо богомерзкого var ;)

кстати автор mybatis раньше (щас фиг его знает, может его ктонить побил уже) принципиально не писал javadoc

ps. хехе, как проект ушел из apache foundation добровольцы таки стали писать доку: https://github.com/mybatis/mybatis-3/commit/fcbea106e6358be20d519c8918a24b90a...

Ну да, с этим я согласен. Но мы же о varе говорим. Если я зайду в код и там varы будут натыканы как грибы, да так, что на каждый результат мне придется идти в метод и т.д. и т.п., то да, скорее всего я выкину такую библиотеку на помойку, ибо не осилю читать такой код, а нервы дороже. Но я думаю что в коде все должно быть пропорционально, и в более менее адекватном коде, будет более менее адекватное применение фич языка. Исключения, конечно же, не в счет.

Ну это все больше исключение, нежели правило. Я уже отписал выше, мне просто нервы дороже. Я не спорю что такие ситуации имеют право на жизнь, я лишь хочу сказать что так быть не должно.

Но мы же о varе говорим.

Напомню:

А еще, на практике я не разу не «анализировал» код библиотеки.

А топик про var, да, но речь про то что код библиотеки это не рокетсайнс и лезть туда надо, иногда зажав нос.

Ну... Осмысленные имена методов и классов чаще всего сильно снижают этот недостаток.

А еще, на практике я не разу не «анализировал» код библиотеки.

Здесь да, погорячился. Поинт в том, чтобы этих ситуаций было как можно меньше.

но речь про то что код библиотеки это не рокетсайнс и лезть туда надо, иногда зажав нос.

Лишь бы тред не скатился в «боль бытия» :)

Так оно, не представьте что вам нужно перелопатить 50-60к строк кода, вы читаете себе беззаботно, потягивая пивка, и тут тебе бац — попадаете на это самое «непонятно». Прыгаете в метод скребя сердцем. Один раз, фиг с ним, читаете дальше. А тут снова бац. И так раз десять а то и больше. И тут в очередной раз вы не выдерживаете и просто пускаете от злости банку пива в монитор, после чего удаляете код, решив что больше не прикоснетесь к этому говну.

Так как вывод типов будет такой же убогий, как в скале, то не нужен.

Нет, но мне как-то везет, наверное. Как будто ты работаешь в толпе, которая не подчиняется никаким гайдлайнам. Если да, то ссзб и это не проблема скалы, а если нет - то твоя личная, раз ты не смог сделать так, чтобы в гайдлайнах ясно было написано, что за такое гвозди под ногти засовывают.

Почему-то большинство оупен-сорса на скале читается вполне вменяемо. Кроме, конечно, монадической херни, которую проще генерировать, чем писать, но тогда ее и читать не нужно.

Если я зайду в код и там varы будут натыканы как грибы, да так, что на каждый результат мне придется идти в метод

Зачем? Идея ведь подсказывает тип переменной/выражения по хоткею.