Это то, что я нашел.
Я думаю, что нет сомнений в том, что имена являются допустимыми на двоичном уровне в COM, поскольку имя интерфейса COM - это его IID, а текстовое имя - просто документация.
На стороне .NET соответствующей спецификацией является спецификация инфраструктуры общего языка (ECMA-335, http://www.ecma -international.org / публикации / стандарты / Ecma-335.htm .) Интересно, добавят ли .NET или Mono свои собственные ограничения сверху - это уменьшит совместимость, но это реальный мир.
Раздел 8.5.1 охватывает допустимые имена типов в Common Type System, ипросто говорит, что имена сравниваются с использованием кодовых точек.Странно, что это ничего не говорит о композиции имени, только как имена сравниваются.Этот раздел перефразируется MSDN по адресу http://msdn.microsoft.com/en-us/library/exy17tbw%28v=VS.85%29.aspx,, в котором говорится, что единственными двумя ограничениями являются (1) имена типов, «закодированные как строки из 16-битных символов Unicode», и (2) они не могут содержатьвстроенный 0x0000.
Я процитировал бит о 16-битном Unicode, а не перефразировал его, потому что он использует неточный язык.Предположительно автор этой страницы имел в виду UTF-16.В любом случае ECMA-335 определяет побайтовое сравнение и не упоминает Unicode (относительно имен типов), а также не запрещает встроенные нули.Возможно .NET здесь отклонился от CTS, хотя я сомневаюсь в этом.Скорее всего, автор этой страницы MSDN думал о языках программирования, когда писал ее.
Спецификация общего языка (также определенная в ECMA-335) определяет правила для идентификаторов в исходном коде.Идентификаторы не имеют непосредственного отношения к моему вопросу, потому что мои внутренние имена типов никогда не появляются в исходном коде, но я все же изучил его.CLS является подмножеством CTS, и поэтому его ограничения не обязательно являются частью более широкой CTS.Правило 4 CLS гласит, что идентификаторы должны соответствовать правилам Приложения 7 к Техническому отчету 15 стандарта Unicode 3.0 - см. http://www.unicode.org/reports/tr15/tr15-18.html. Этот документ также немного расплывчат в том смысле, что он относится к «другой букве» и «соединителю».пунктуации ", но не определяет их.Это помогло: http://notes.jschutz.net/topics/unicode/.
Раздел 8.5.1 спецификации ECMA содержит ненормативное примечание о том, что потребителю CLS (например, C # или браузеру типов Visual Studio, я полагаю) «не нужно потреблять типы, которыенарушать правило 4 CLS. Мои предложенные имена интерфейсов нарушают это правило 4. Похоже, это примечание подразумевает, что допустимый тип может иметь имя, которое нарушает правило 4, и что потребитель CLS должен либо принять мошенническое имя, либо безопасно его игнорировать.(Браузер типов Visual Studio отображает его без жалоб.)
Таким образом, мои предложенные имена типов, как правило, недопустимы в исходном коде.Но обратите внимание, что в разделе 10.1 (об идентификаторах в CLS) сказано: «Поскольку его правила применяются только к элементам, экспортируемым на другие языки, частные члены или типы, которые не экспортируются из сборки, могут использовать любые имена, которые они выберут».
Я пришел к выводу, что использовать символы # @ безопасно!в именах моих типов до тех пор, пока они остаются в двоичном домене и не должны появляться ни в исходном коде, ни вне сборки.И на самом деле они никогда не используются вне COM-сервера.
Слово о защите будущего ... CTS почти ничего не говорит о композиции имен типов, несмотря на наличие раздела под названием «Действительный».имена »(раздел 8.5.1).Они могут изменить это в будущем, но эта широкая и либеральная спецификация предложила нам всем делать то, что нам нравится.Если бы дизайнеры CTS хотели оставить место для изменений, то они наверняка ввели бы какое-то положение для этого или, по крайней мере, были бы менее щедрыми.