Здравствуйте, ·, Вы писали:

.>>> В отличие от всяких шарпов — типы сохраняются, а не "всё — строки".
vsb>>Сохраняется тип значения, а не тип выражения.
·>Эээ.. ну да. Но тип значения даже точнее. Или что ты имеешь в виду?

Я имею в виду, что в теории компилятор знает значение выражения `name` и мог бы его передавать как-нибудь. Кстати это позволило бы получить информацию про generic типы, если вдруг кому-то надо.

vsb>>>>Если взять тот же пример с SQL, то в JDBC в общем случае требуется указывать тип аргумента.
vsb>>·>Не надо. Есть же тип у выражения.
vsb>>·>

vsb>>·>int age = 18;
vsb>>·>String name = "vasya";
vsb>>·>db."insert...\{age} \{name}"
vsb>>·>

vsb>>·>Тебе внутрь шаблона придёт List.of(18, "vasya") для каждого элемена можно сделать instanceof и соответсвующие маппинги типов.

vsb>>А теперь то же самое для случая, когда name == null.
·>А, понял. А setObject разве не сработает с java.sql.Types.NULL?

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

·>Но суть даже не в этом. Всё равно я не вижу нужды в каком-то новом особом магическом синтаксисе \{name:VARCHAR2}. У нас же там java код и можно оборачивать как обычный код. Если тебе не нравится \{arg(name, VARCHAR2)} можно запилить например \{DB.VARCHAR2(name)}. Может буковок и чуть больше, но ведь это обычный java-код, который будет обычным образом авто-комплититься, рефакториться, навигироваться, етс.

Суть фичи ведь в том, чтобы писать код, который компактней и понятней. Так-то можно и вообще без неё обходиться, как сейчас обходимся. А авто-комплититься и рефакториться будет любой синтаксис, не думаю, что для IDE есть разница, поддерживать только синтаксис \(expr) или ещё и \(expr: String).

vsb>>>>Т.е. правильный код должен выглядеть примерно так:
vsb>>·>Нет, или я не понял что именно ты имеешь в виду, что делать с этим VARCHAR2?
vsb>>Передавать его в PreparedStatement.setObject.
·>Тут ведь как — это будет всё равно гораздо лучше, чем есть на сегодняшний день.

Фича классная, тут я не спорю. Я на самом деле когда-то в котлине агитировал сделать такую фичу, но не прислушались. А тут — в жаве почти что мне хочется.

vsb>>Ну как я и написал — парсить строку самому. Если это, к примеру, SQL, то сразу будет куча нюансов, чтобы не было совпадения синтаксиса с чем-нибудь. Не идеально.
·>А кто по-твоему должен парсить магию "\{name:VARCHAR2}"?

Что-то парсит компилятор, то, что после ":" — в случае FMT передаётся как обычная строка, в случае SQL, конечно, хотелось бы какого-то дополнения от IDE, а не просто обычную строку (хотя и так подошло бы). Тут надо подумать, как сделать это так, чтобы оба варианта работали.

vsb>> Опять же две функции — STR и FMT вместо одной универсальной.
·>Так ведь у них разные предназначения. STR это замена "aa" + n + "bb", а FMT это форматтер со своим синтаксисом. print vs printf

А если мне надо и то и то? Сейчас это FMT"map[%s\(key)] = %08x\(value)". А могло бы быть STR"map[\(key)] = \(value:08x)".