Я читаю .Net Docs и наткнулся на термин "верность",
Type safety is also used to help enforce encapsulation by guaranteeing the fidelity of the accessor keywords.
Что это означает (по отношению к ключевым словам доступа)?
Насколько я могу судить, термин «аксессор» здесь неверен... это должно быть «доступность» или «видимость», ссылаясь на ключевые слова public и т. д., потому что речь идет о том, что может вызывать другой код. Я думаю, что это способствует путанице. Помимо этого, неясно... возможно, это относится к согласованности и достоверности состояния объекта и предотвращению произвольных изменений объекта потребителями. Однако это всего лишь документ «тура», так что не зацикливайтесь на высокоуровневых описаниях.
Количество ошибок в этом документе большой. Святое благо. Я нашел полдюжины всего за пару абзацев.
@EricLippert - я рад, что ты это сказал. Я думал, что схожу с ума, просто глядя на этот кусочек.





Вздох.
Просто слишком много документации, и у команды разработчиков недостаточно времени, чтобы проверить ее на точность в жаргоне. Этот обзор представляет собой беспорядок небольших ошибок и сбивающих с толку нестандартных жаргонных терминов.
Рассматриваемый абзац:
Type safety is also used to help enforce encapsulation by guaranteeing the fidelity of the accessor keywords. Accessor keywords are artifacts which control access to members of a given type by other code. These are usually used for various kinds of data within a type that are used to manage its behavior.
Фу. Здесь так много неправильного. «ключевое слово доступа» должно быть «уровнем доступности». «Другой код» сбивает с толку; «другой код» означает код, который точно разное, чем какие? Модификаторы доступности управляют доступом к членам где угодно, а не только в «другом коде». Почему мы говорим о члены, а потом вдруг переключаемся на данные? Что означает «управлять поведением»?
Давайте перефразируем, используя стандартный жаргон C#.
Static type checking helps enforce encapsulation by ensuring that a program respects the accessibility levels declared by a member of a type. For example, if type
Doghas a private membermother, then static type checking helps ensure that attempts to access that member from code outside theDogclass will be prevented.
Исправление всех остальных сумасшедших ошибок в этом документе оставлено читателю в качестве упражнения. Например, что не так с этим примером кода?
Dog dog = AnimalShelter.AdoptDog(); // Returns a Dog type.
Pet pet = (Pet)dog; // Dog derives from Pet.
pet.ActCute();
Car car = (Car)dog; // Will throw - no relationship between Car and Dog.
object temp = (object)dog; // Legal - a Dog is an object.
Я вошел в проблему github с MORE RANTING. github.com/dotnet/docs/issues/13466
Car car = (Car)dog; : Ну, если вы настаиваете на том, чтобы Car было разрешено наследовать от Dog: i.stack.imgur.com/eoTFN.jpg@EricLippert - с этим образцом кода так много не так. Для начала Автомобиль автомобиль = (Автомобиль) собака; не будет вызывать исключение времени выполнения... оно просто не будет компилироваться.
Во-вторых, может быть один способ компиляции, но его реализация будет в основном бесполезной, вводящей в заблуждение и опасной. Однако это доходит до того, что документация просто неверна на многих уровнях. Если разработчик реализовал статический оператор явного преобразования. открытый статический явный оператор Car(Dog d) => (Car) null;
Но тогда бы не кинул!
Компилируется и выбрасывается, если, скажем, машина — это интерфейс, а собака распечатана.
@EricLippert - Верно, спасибо за разъяснения. Я думал только о том, что пример кода плохой, неполный и вводящий в заблуждение.
Жаль, что на сегодняшний день документация все еще содержит это вводящее в заблуждение описание...
Не могли бы вы дать ссылку на страницу, где появляется термин «верность»?