2012-03-21 3 views
5

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

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

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

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

Есть ли актуальные проблемы с отключением соответствия CLS библиотекам? Любой real проблемы с этим?

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

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

И нет, это не дубликат обратного этого вопроса: Any reason not to mark a DLL as CLSCompliant?

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

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

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

+0

-1. Ни один из случаев, которые вы приводите в качестве примера, не имеет никакого смысла. – TomTom

+0

@TomTom: Я согласен, таким образом, мой ответ ниже, но я все еще думаю, что вопрос сам по себе действителен. Существуют и другие допустимые случаи, которые препятствуют соблюдению CLS. Один пример из моего текущего проекта: название проекта - REM. Корневое пространство имен всех проектов в решении - 'Rem.'. Если REM является зарезервированным ключевым словом на некоторых языках, это предотвращает соответствие CLS. –

+0

Да. IO - просто поклонник hugh, делающий случай ПРАВИЛЬНО или смеясь. ОП все время держал мир, чтобы сесть и придумать ОДИН разумный случай. – TomTom

ответ

5

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

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

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

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

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

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

+0

Спасибо! Кто-то, кто сосредоточился на самом вопросе. Ты восхитителен! –

4

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

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

Заключение: Обычно существует no для защищенных или даже общедоступных переменных. Его можно моделировать с использованием свойств.

+0

@ Даниэль Обычно ты прав. Но иногда бывают случаи, когда подкласс должен иметь возможность обойти проверку, которая возникает в публичном сеттере. Другим случаем является недействительность в публичном сеттере, но подкласс должен иметь возможность контролировать или избегать этого недействительности. –

+0

В нижней строке - когда библиотека, которую вы начали в 2007 году, имеет более 50 плагинов и интегрирована в более 10 000 систем, переименование защищенных переменных просто для того, чтобы сделать компилятор счастливым, не является отличным вариантом. –

+2

@ComputerLinguist: Я до сих пор не использовал для этого защищенное поле. Я бы использовал правильно названные методы для этого случая, потому что они очень четко сообщают о намерениях. В вашем случае кто-то, читающий код вашего производного класса, должен знать, что публичный установщик свойства в базовом классе делает то, чего вы хотите избежать, и именно поэтому вы напрямую обращаетесь к полю. Метод «SetAgeWithoutValidation» сделает ваше намерение очевидным. –

 Смежные вопросы

  • Нет связанных вопросов^_^