Почему разрешено выполнение кода Java в комментариях с определенными символами Unicode?

Или ограничьте использование \ uxxxx идентификаторами, строковыми литералами и символьными константами. Что и делает C11.

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

Я согласен, это не «ошибка дизайна» Java, а ошибка IDE.

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

@Phil: это выглядит как комментарий только при просмотре с помощью определенных инструментов, другие показывают это иначе.

@jmoreno не должно быть иметь , чтобы иметь что-то большее, чем текстовый редактор для чтения кода. По крайней мере, это нарушает принцип наименьшего удивления, а именно то, что комментарии в стиле // продолжаются до следующего символа \ n, а не до любой другой последовательности, которая в конечном итоге заменяется на \ n. Комментарии никогда не должны быть ничем иным, кроме как вырезанными. Плохой препроцессор.

Итак, чтобы задать вопрос, мы должны уже знать ответ, чтобы подтвердить, что наш вопрос действительно действителен? Я не думаю, что вопрос «недействителен», хотя он может содержать неверное предположение.

В настоящее время мы используем UTF-8 для нашего исходного кода и можем использовать символы Unicode напрямую, без необходимости экранирования.

Интересно, что native2ascii, похоже, не использует синтаксис \uu...xxxx,

Да, native2ascii был предназначен для помощи в подготовке пакетов ресурсов путем преобразования их в iso-latin-1, поскольку Properties.load был исправлен для чтения только latin-1. И там правила другие, нет синтаксиса \uuu… и нет стадии ранней обработки. В файлах свойств property=multi\u000aline действительно совпадает с property=multi\nline. (Вопреки фразе «использование экранирования Unicode, как определено в разделе 3.3 Спецификации языка Java ™» документации)

Обратите внимание, что эта цель дизайна могла быть достигнута без каких-либо бородавок; проще всего было бы запретить экранирование \u для генерации символов в диапазоне U + 0000–007F. (Все такие символы могут быть изначально представлены всеми национальными кодировками, которые были актуальны в 1990-х годах - ну, может быть, кроме некоторых управляющих символов, но они вам и не нужны для написания Java.)

@zwol: ну, если вы исключите управляющие символы, которые в любом случае не разрешены в исходном коде Java, вы правы. Тем не менее, это потребовало бы усложнения правил. А сегодня уже поздно обсуждать решение ...

ну проблема с сохранением документа в utf8 а не на латыни или еще как-то. Все мои базы данных тоже были сломаны из-за этой западной чепухи

Я думаю, вы не торопитесь, где в API используются символы, отличные от ASCII. Есть люди, использующие его (не я), например в странах Азии. А когда вы используете в идентификаторах символы, отличные от ASCII, запрещать их в комментариях к документации не имеет смысла. Тем не менее, разрешить им внутри токена и позволить им изменить значение или границы токена - это разные вещи.

они могут использовать правильную кодировку файлов. зачем писать int \u5431, когда можно int 整

Что вы будете делать, когда вы должны скомпилировать код для их API и не можете использовать правильную кодировку (предположим, что в 1995 году не было широко распространенной поддержки UTF-8). Вам просто нужно вызвать один метод и вы не хотите устанавливать пакет поддержки азиатских языков в вашей операционной системе (помните, девяностые годы) для этого единственного метода ...

Это воображаемый сценарий? Я не думаю, что это происходит в реальном мире.

Было бы еще хуже, если бы в идентификаторах были разрешены произвольные символы, но в то же время доступ к этим идентификаторам из определенных локалей был невозможен. Когда вы создаете язык, вам следует принять решение. Я могу жить с языком, ограничивающим символы ASCII, поскольку я вижу проблемы с локализованным исходным кодом. Но я также являюсь активным пользователем полностью англоязычного сайта coderhelper, поэтому у меня (и, вероятно, у вас тоже) есть предубеждения. Мы знаем, чего стоит иметь возможность поговорить о коде с другими (на международном сайте). Кстати, я оставил ответ, объясняющий первоначальное намерение (правда)…

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

@Holger: идентификаторы, отличные от ASCII, - еще одна баня червей, поскольку они не только буквенно-цифровые, но и содержат слишком много, включая управляющие коды: coderhelper.com/questions/4838507/…

Не думаю, что это изменилось. Документация по Java также большую часть времени была полностью англоязычной. Некоторое время поддерживался японский перевод, но поддержка двух языков на самом деле не поддерживает идею поддержки его для всех регионов мира (скорее, это опровергает). А до этого все равно не существовало основного языка с поддержкой Unicode в идентификаторах. Так что, я полагаю, кто-то подумал, , что локализованный исходный код станет следующим большим достижением. Я бы сказал, , к счастью, , не взлетело.

@ninjalj: да, мне нравится то, что вы можете делать со встроенным письмом справа налево, но также и такие простые вещи, как тот факт, что ä и ä - разные идентификаторы (потому что один из них U+0061U+0308, а другой U+00E4).

@Holger: сам RTL тоже может сбивать с толку. Возник вопрос, который я не могу найти прямо сейчас, когда OP пытался сопоставить подстроку в строке: аргументы были поменяны местами.

@StephenP - вы, вероятно, думаете %n в format(). \n означает именно символ 0x0a, см. docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.6

@ bayou.io Я считаю, что юникод может быть действителен в комментарии ... более конкретно, документирующий комментарий / ** ... * / с описанием, которое будет сгенерировано в HTML-странице javadoc; теперь в этом случае я бы, вероятно, по-прежнему использовал буквальную новую строку над этим, а для документирующего комментария он не столкнулся бы с этой проблемой, если бы у меня не было символов Юникода для ОБЕИХ * и / в комментарии непосредственно друг за другом, потому что документирование комментариев не заканчиваются одним символом новой строки.

@anonymous - хороший момент. однако мы можем использовать здесь экранирование xml - ⪹ -> ⪹

@ bayou.io Что мне делать, когда мне нужно смоделировать что-то, что не имеет английского названия? Это довольно распространено, если вы когда-либо имели дело с такими доменами, как право, бизнес или тому подобное, в которых этих вещей нет. Слова имеют очень специфические значения, особенно в юридических областях. Представьте, что в стандартном алфавите не было C, X или Q. Теперь у вас есть класс под названием KommonLaw или что-то в этом роде. Вы бы хотели использовать букву «C». В вашем мире это неправильно. Но что, если KommonLaw имел в виду что-то другое. Что теперь? В какой-то момент вы, вероятно, попытались бы использовать язык, который позволил бы вам использовать вместо этого 'C'.

@ HaakonLøtveit - нельзя использовать символ напрямую вместо escape-последовательности, например class Løtveit вместо class L\u00D8tveit

Это отлично подойдет для меня, но тогда вам нужно будет где-нибудь написать "new Løe ()", и вы, вероятно, очень скоро устанете от копирования 'ø' очень скоро. Скорее всего, это упростит ваше рассудок. (Или вы бы просто использовали международную раскладку IBM, но это потому, что она поддерживает большинство западноевропейских символов. Но есть пиньинь и т. Д.)

@ HaakonLøtveit - у меня не было типа или копии @HaakonLøtveit, редактор делает это за меня с помощью автозаполнения. То же самое для Java. Даже если мне придется скопировать ø, это, вероятно, будет проще, чем найти и ввести его юникод.

да. Ваш редактор сегодня, в 2016 году, сделает это. Но Java была выпущена в 1995 году. В то время в Emacs не было семантического автодополнения, и это была самая продвинутая вещь, доступная для Java. У него даже не было поддержки юникода.

Я бы не стал говорить, что это ошибка дизайна . Я мог бы согласиться с вами, что это был неудачный выбор дизайна или выбор с печальными последствиями, но я все же думаю, что он работает так, как задумывали разработчики языка: он позволяет вам использовать любой символ Юникода в любом месте файла, сохраняя при этом кодировку ASCII файла.

Я бы подумал, что если бы обоснование было таким, как указано, то обратная косая черта, за которой следует какой-то конкретный другой символ (например, !), должна была указывать на то, что остаток физической строки следует игнорировать, а первый символ следующей строки следует рассматривать как непосредственно после символа перед обратной косой чертой. Это позволит пробить \! в столбцах 71-72, оставив восемь столбцов доступными для порядковых номеров. В некоторых случаях трюк с полосой маркера может уменьшить потребность в машиночитаемых числах, но я не думаю, что он устранит его.

При этом я думаю, что выбор этапа обработки для \u был менее абсурдным, чем решение последовать примеру C в использовании начальных нулей для восьмеричной записи. Хотя восьмеричная нотация иногда бывает полезна, я еще не слышал, чтобы кто-нибудь излагал аргумент, почему ведущий ноль - хороший способ обозначить это.

@supercat Люди, которые добавили эту функцию в C89, обобщали поведение исходного препроцессора K&R, а не разрабатывали функцию с нуля. Я сомневаюсь, что они были знакомы с передовыми методами работы с перфокартами, и я также сомневаюсь, что эта функция когда-либо использовалась по назначению, за исключением, возможно, одного или двух упражнений по ретрокомпьютингу.

@supercat У меня не было бы проблем с Java \u в качестве преобразования до токенизации, если бы было запрещено создавать символы в диапазоне U + 0000..U + 007F. Комбинация «это работает везде» и «это псевдонимы символов ASCII с синтаксической значимостью» понижает его уровень с неудобного до совершенно неправильного.

@zwol: Я мог бы согласиться с этим, хотя в целом я не большой поклонник подхода языков к идентификаторам, отличным от ASCII. Поскольку Unicode включает в себя множество гомоглифов, а языки, которые позволяют использовать идентификаторы Unicode, часто накладывают минимальные ограничения на их использование, чрезвычайно сложно создать список программ, который был бы удобочитаемым, но семантически однозначным.

@supercat Да, даже собственные рекомендации Unicode о том, как создавать идентификаторы в языках программирования, слишком слабы, чтобы мне было комфортно с ними.

@zwol: Лично я считаю, что языки программирования должны определять жесткие и свободные критерии сопоставления и требовать, чтобы идентификаторы точно совпадали, чтобы их можно было считать совпадением, но должны затенять все идентификаторы, которые слабо совпадают (такое правило должно применяться к верхнему / нижнему регистру в ASCII, но также и во многих сценариях Unicode). Таким образом, если Foo определен во внешнем контексте, а foo определен во внутреннем, то во внутреннем контексте foo будет относиться к последнему идентификатору, а Foo будет синтаксической ошибкой. Применение такого правила к гомоглифам, но со средствами его отмены в особых случаях ...

... (например, явное указание компилятору «Я хочу, чтобы идентификаторы foo и Foo или Χ и X были доступны здесь оба) поможет защититься от множества неоднозначных ситуаций.

@supercat: сегодня это делают IDE. «Критерий свободного соответствия» часто состоит из одной буквы, затем IDE заполняет оставшиеся символы, чтобы сделать его подходящим «критерием строгого соответствия», и я не думаю, что компиляторы когда-либо должны иметь дело с «критериями свободного сопоставления». То есть, у меня нет компилятора, который успешно разрешает вхождение i в I, и когда кто-то компилирует его на турецком языке, i внезапно преобразуется в İ…

@Holger: В соответствии с правилами, которые я хотел бы видеть, в области действия, в которой был определен Six, идентификаторы six, SİX, Sıx и т. Д. Не будут использоваться, даже если они существуют во внешних областях. . Коллизии могут привести к синтаксическим ошибкам, которые требуют явной директивы «различать эти идентификаторы», но не могут изменить значение кода, который все еще скомпилирован.

О вашем "для педантов": Конечно, в то время однострочного комментария // не существовало. И поскольку в C есть терминатор оператора, который не является новой строкой, он в основном будет использоваться для длинных строк, за исключением того, что, насколько я могу определить, «конкатенация строкового литерала» была там от K&R.