Практические ограничения для сборок, не помеченных как совместимые с CLS? - PullRequest
Новая
       34

Практические ограничения для сборок, не помеченных как совместимые с CLS?

5 голосов
/ 21 марта 2012

Как автор библиотеки OSS, я всегда старался сделать свои вещи совместимыми с CLS. Но MS не делает это легко. Они часто ставят вас в ловушку 22 ситуаций, таких как:

  • Вы не можете иметь защищенную переменную, отличающуюся только регистром от общего свойства.
  • Вы не можете иметь защищенные или общедоступные переменные, начинающиеся с подчеркивания или 'm_'.
  • Если вы хотите сделать класс действительно расширяемым, вам часто нужно , чтобы иметь защищенные переменные, соответствующие открытым свойствам. Ваш наименее уродливый выход - добавить к переменной суффикс, такой как «Var» или «Value». Это противно и неприемлемо для меня. Мне нравится чистый код.

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

Я устал от предупреждений, и я планирую отключить соответствие CLS на уровне сборки в моих 30+ библиотеках C #.

Есть ли реальные проблемы с отключением CLS-совместимости для библиотек? Есть ли настоящие проблемы с этим?

Microsoft издавала непослушное руководство по программному обеспечению в течение десятилетий, при этом менее 5% от него стоило тех байтов, в которых оно было закодировано. Я не могу найти никаких доказательств того, что эта лучшая практика имеет какой-либо реальный эффект на что угодно.

Но, чтобы быть осторожным, я проверяю.

И нет, это не дубликат этого вопроса: Есть ли причина не отмечать DLL как CLSC-совместимую?

Я ищу реальные результаты и эффекты здесь, а не совет стажера MS.

Например, если IronPython, IronRuby или F # не могут прочитать или записать переменную, начинающуюся с подчеркивания, это является эффектом, хотя это вызовет проблемы только у пользователей, создающих подклассы определенных объектов.

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

Ответы [ 2 ]

5 голосов
/ 21 марта 2012

Из того, что я могу сказать, фактическая или реальная проблема с несоответствием составляет вы теряете гарантию .

http://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx

Это похоже на разгон вашего компьютера или вождение автомобиля с сторонним модом, вы теряете «официальную» поддержку от людей, которые изначально поставляли вам, если что-то пойдет не так (даже если это сработает).

В случае соответствия CLS вы теряете поддержку от MS в отношении совместимости вашего кода с другими языками (мой собственный акцент):

Если вы разрабатываете CLS-совместимый классбиблиотека, ваша библиотека будет иметь гарантию взаимодействия с широким спектром языков программирования

Что касается всех catch-22, я понятия не имею.Не могу сказать, что когда-либо заботился о соответствии CLS.

4 голосов
/ 21 марта 2012

О проблеме, которую вы использовали в качестве примера:

  • Если у открытого свойства есть открытый установщик и получатель, защищенная переменная не нужна, потому что производные классы могут устанавливать значение с помощью открытого свойства.
  • Если публичное свойство не имеет публичного установщика, предоставьте ему защищенный установщик.Это устраняет необходимость в защищенной переменной, поскольку производные классы могут устанавливать значение с помощью защищенного установщика открытого свойства.
  • Следует полностью избегать открытых переменных.

Вывод: Естьобычно нет необходимость в защищенных или даже открытых переменных.Все это можно смоделировать с помощью свойств.

...