Причем тут «пример использования кода в документации»? Почему бы уже тогда к интерфейсу не приделать конструктор с деструктором, если уж пошла такая пьянка.
Вот как раз в «типовом DI» вам не могут прийти снаружи null-значения сервисов, и поля с ними тоже после конструктора не могут быть null.
В идеале да, не должны. ITest _testXXX;
class ZZZ(ITest value)
{
_testXXX.Fn(); <-- банальная опечатка
_testXXX = value;
}
А между созданием и инициализацией в каком состоянии будет? какая-то религия мне запрещает написать кривой код и в конструкторе накосячить, дернув не проинициализированый интерфейс?
Подождите, но зачем вы включали эти предупреждения?
Открываем исходник и фиг понимем «оно null или не null? А opt включена или нет ?»
Это же «очевидно»… или нет?
Допустимым значением.
Это каким например?
Создаем экземпляр класса, в конструкторе по умолчанию «ничего нет», можно провести «ленивую инициализацию» — но у нас же «null» не может быть? А что тогда? Создавать по всему коду экземпляры классов только что бы «ублажить» компилятор?
Сама по себе фича полезная. Code contracts отлично ловили такие ошибки на этапе компиляции. Но реализация — выглядит более чем сомнительно.
По стандарту языка — ссылочный тип или null или «что-то есть».
Нафига городить на уровне языка проверку «рук от бедер», тем более что сейчас компилятор не пропускает не проинициализированные переменные?
Ну в C# постоянно синтаксис изменяется и обратно он несовместим, странно иметь новые языковые фичи которые в зависимости от версии окружения по разному бы читались.
Всегда декларировалось, что интерфейс это декларация-контракт взаимодействия. Реализация — этим занимаются другие сущности.
А тут предлагают «улучшить» эти соглашения, только потому что кто-то «убил» множественное наследование классов, потому что это «будет сложно».
Может просто разрешить множественно наследование классов, чем так извращаться, причем ломая привычные соглашения?
или это очередной Vendor lock в исполнении M$?
IWeapon cantBeNull;
…
Проблема такого изменения в том, что мы прерываем совместимость со старой кодовой базой: Здесь предполагается, что все переменные в старом коде по умолчанию не могут содержать null. Чтобы справиться с этой ситуацией, статические анализаторы компилятора на null-безопасность должны быть выборочно включены в зависимости от проекта.
У вас 15-летний код, и тут вдруг «Ай, ваш код шлак, у вас может быть null значение, срочно нужно переколбасить ваш код (вы же идиот и до сих пор об этом не подумали) или выключите нафиг наши предупреждения».
Нормальная адекватная логика.
Да и логика «не могут содержать null» подразумевает, что чем-то должна быть инициализирована переменная по умолчанию? Чем?
Отличная идея — сломать обратную совместимость по синтаксису.
Похожа на идею — значение True равно 0. Во где был фееричный треш на унаследованном коде.
Default Interface Methods
Отличная идея, только кофеварку забыли приделать и пемзу для пяток…
В отличие от множественного наследования, данный функционал позволяет избежать проблемы ромбовидного наследования, при которой метод с одним и тем же именем определен в нескольких интерфейсах. Для этого C# 8.0 требует, чтобы каждый класс и интерфейс имели наиболее специфическое переопределение каждого унаследованного члена:
В С++ уже лет 16 назад это не было проблемой. А в .Net это объяили «Злом», предали анафеме, а сейчас впихивают обратно. Правда почему-то ректально…
Про эти док станции я знаю. Именно им ищу альтернативы.
Недавно обнаружил, что мониторы Samsung S24H850QF*/S27H850QF* могу избразить что-то подобное:
USB Type-C
Согласно спецификации USB Power Delivery 2.0, данное изделие может заряжать ваш ноутбук, если он подключен к изделию с помощью кабеля USB Type-C.
― Поддерживается максимальное питание зарядки 45 Вт. Скорость зарядки зависит от ноутбука, подключенного к изделию.
Устройство можно использовать в качестве концентратора, подключив его к компьютеру с помощью кабеля USB Type-C. Можно напрямую подключить устройство-источник сигнала к монитору и управлять им с монитора, не подключая к компьютеру.
И
philips 258b6queb/00
Подача питания по USB C Max./60W
20V/3A, 12V/3A, 8V/3A, 5V/3A(Зависит от устройства)
А разве можно заставить чиновника использовать конкретную модель телефона?
Нет. Заставлять никто не будет. Просто при аресте чиновника распотрошат его мобилки, там найдут пару-тройку рабочих документов и добавят срок, дабы другим не повадно было.
Или возьмут пару чиновников, им отправят пару документов с грифом ДСП, потом эти документы найдут в публичном доступе/мобилках (вот Мегафон и оборудование закупает для закона Яровой). Публично накажут, и закон оправдают «вот смотрите какой полезный закон. педофила-наркомана не поймали, зато поймали чиновника-болтуна, который, как известно, находка для шпиона, потенциально шпиона террористов». И все в шоколаде.
Никого принуждать и не нужно будет. Сами с воем побегут покупать и пользоваться :)
Может просто сотню голов на колбасу пустили, а дальше ученые в контрольные точки 5-10-15- т.д. минут «оживляли» и замеряли контрольные параметры. смотрели время когда перестанет срабатывать их смесь
Externally, an assembly is a collection of exported resources, including types. Resources are exported by name.
…
The identity of a type is its assembly scope and its declared name. A type defined identically in two different assemblies is considered two different types.
…
New types—value types and reference types—are introduced into the CTS via type declarations expressed in metadata. In addition, metadata is a structured way to represent all information that the CLI uses to locate and load classes, lay out instances in memory, resolve method invocations, translate CIL to native code, enforce security, and set up runtime context boundaries. Every CLI PE/COFF module (see Partition II Metadata – File Format) carries a compact metadata binary
that is emitted into the module by the CLI-enabled development tool or compiler.
…
Each CLI component carries the metadata for declarations, implementations, and references
specific to that component. Therefore, the component-specific metadata is referred to as component metadata, and the resulting component is said to be self-describing. In object models such as COM or CORBA, this information is represented by a combination of typelibs, IDL files, DLLRegisterServer, and a myriad of custom files in disparate formats and separate from the actual executable file. In contrast, the metadata is a fundamental part of a CLI component.
…
When a class is loaded at runtime, the CLI loader imports the metadata into its own in-memory data structures, which can be browsed via the CLI Reflection services. The Reflection services should be considered as similar to a compiler; they automatically walk the inheritance hierarchy to obtain information about inherited methods and fields, they have rules about hiding by name or name-and-signature, rules about inheritance of methods and properties, and so forth.
…
A metadata token is an implementation-dependent encoding mechanism. Partition II describes the manner in which metadata tokens are embedded in various sections of a CLI PE/COFF module. Metadata tokens are embedded in CIL and native code to encode method invocations and field accesses at call sites; the token is used by various infrastructure services to retrieve information from metadata about the reference and the type on which it was scoped in order to resolve the reference.
A metadata token is a typed identifier of a metadata object (such as type declaration and member declaration). Given a token, its type can be determined and it is possible to retrieve the specific metadata attributes for that metadata object. However, a metadata token is not a persistent identifier. Rather it is scoped to a specific metadata binary. A metadata token is represented as an index into a metadata data structure, so access is fast and direct.
Глянул в 'WebAssembly Core Specification':
5. Binary Format
5.3. Types
5.3.1. Value Types
…
Value types are encoded by a single byte.
valtype::=0x7F => i32
valtype::=0x7E => i64
valtype::=0x7D => f32
valtype::=0x7C => f64
…
Так что насчет "… должен знать типы… если поменялось то обнаружить только тестами..." и тут ответ похоже «да должен знать» и «да только тестами проверить»
Это все было бы круто, если бы потом не надо было делать каст, внутри которого .net все равно сделает проверку типа.
Тут согласен — не очень рационально использовать велосипед вместо уже сделанного и отпимизированного.
А зачем тогда придумали «To fully identify a type, the type name shall be qualified by the scope that includes the type name.»?
Опять же, зачем то сделали:
Type signatures
Type signatures define the constraints on a value and its usage. A type, by itself, is a valid type signature. The type signature of a value cannot be determined by examining the value or even by knowing the class type of the value. The type signature of a value is derived from the location signature (see below) of the location from which the value is loaded or from the operation that computes it. Normally the type signature of a value is the type in the location signature from which the value is loaded.
Не вижу проблем, при загрузке или компиляции генерить уникальные идентификаторы/хеши типов для быстрой проверки. Не парсить же описание типов каждый раз при каждом обращении.
Возможно Type.GUID Property уже служит для этих оптимизаций.
COM такой механизм опознавания типов использовал.
Это не новая идея и уже была реализована.
Эээ… там нет механизмов защиты, ровно наоборот. Если вы про исходный коммент, конечно, а не про что-то свое.
Не вижу смысла оспаривать документацию по .Net CLI VM:
…
The verification algorithm shall attempt to associate a valid stack state with every CIL instruction. The stack state specifies the number of slots on the CIL stack at that point in the code and for each slot a required type that shall be present in that slot.
…
The verification algorithm shall simulate all possible control flow paths through the code and ensure that a valid stack state exists for every reachable CIL instruction.
…
Verification simulates the operation of each CIL instruction to compute the new stack state, and any type mismatch between the specified conditions on the stack state and the simulated stack state shall cause the verification algorithm to fail.
…
The VES ensures that both special constraints and type constraints are satisfied. The constraints can be checked
as early as when a closed type is constructed, or as late as when a method on the constrained generic type is invoked, a constrained generic method is invoked, a field in a constrained generic type is accessed, or an instance of a constrained generic type is created.
…
A CIL instruction can throw a range of exceptions. The CLI can also throw the general purpose exception called ExecutionEngineException.
…
и т.д. Там много такого люботыного.
Например открываем документацию для С++ и читаем:
Buffer Security Check
Security Checks
On functions that the compiler recognizes as subject to buffer overrun problems, the compiler allocates space on the stack before the return address. On function entry, the allocated space is loaded with a security cookie that is computed once at module load. On function exit, and during frame unwinding on 64-bit operating systems, a helper function is called to make sure that the value of the cookie is still the same. A different value indicates that an overwrite of the stack may have occurred. If a different value is detected, the process is terminated.
если это все называется "… там нет механизмов защиты ..." боюсь тогда представить тогда что такое "… там есть механизмы защиты ..." :)
p.s.
Предлагаю пока закругляться с этим вопросом и возможно вернуться к нему позже :)
Исходя из декларации назначения механизмов защиты упоминаемых выше, их назначение в уменьшение ущерба в случае человеческих ошибок, намеренных действий или аппартных ошибок.
Стратегия строится на как можно раннем этапе предотвращения ошибок такими методами:
язык разработки
инструменты анализа
внедрение «защитного» кода на этапе компиляции (example: Check for arithmetic overflow/underflow, Buffer Security Check, Run-Time Error Checks) & etc
аппаратные, как последняя линия обороны
в стандартном решении со статической типизацией.
Это превентивный мехнизм, но он не помогает в процессе исполнения. В Runtime приходится применять другие механизмы. .Net предлагает свои механизмы, Java свои. А С++ например практически таких механизмов не предлагает и полагается в этом вопросе на разработчика.
BTW, вызова метода у вас не получилось, у вас упало-то ощутимо раньше.
Да. Это сработал один из защитных механизмов .Net в Runtime (проверил описание типов и цепочки наследования, согласно приведенным выше цитатам из стандартов для .Net). А на уровне спецификации языка «Object references are not blittable.» и соответсвующая ошибк компилятора: error CS0208: Cannot take the address of, get the size of, or declare a pointer to a managed type
Для С++ будет ошибка типа «Unhandled exception in BlaBlaBla.exe 0xC0000005 access violation» или «Unhandled exception at 0x7715A849 (ntdll.dll) in BlaBlaBla.exe: 0xC0000374: A heap has been corrupted (parameters: 0x77195910).» или еще черти что выпадет.
Сейчас с этим значительно лучше стало — средства разработки улучшились и «поумнели»
В идеале да, не должны.
ITest _testXXX;
class ZZZ(ITest value)
{
_testXXX.Fn(); <-- банальная опечатка
_testXXX = value;
}
А между созданием и инициализацией в каком состоянии будет? какая-то религия мне запрещает написать кривой код и в конструкторе накосячить, дернув не проинициализированый интерфейс?
...
Warning CS0649 Field 'Program._interfaceXXX' is never assigned to, and will always have its default value null.
Смысл то не в полях /переменных, а в том, что уже достаточно инструментальных средств что бы не выстрелить себе в ногу.
На мой взгляд.
Я то помню, а вот компилятор похоже забыл об этом :)
...
ITest interfaceXXX;
...
interfaceXXX.FN();
Error CS0165 Use of unassigned local variable 'interfaceXXX'
А конкретнее? null? a default для ссылочных типов случаем не null ?!
Или сделаем еще один тип nullnull или IAmSureNull? :)
Открываем исходник и фиг понимем «оно null или не null? А opt включена или нет ?»
Это же «очевидно»… или нет?
Это каким например?
Создаем экземпляр класса, в конструкторе по умолчанию «ничего нет», можно провести «ленивую инициализацию» — но у нас же «null» не может быть? А что тогда? Создавать по всему коду экземпляры классов только что бы «ублажить» компилятор?
Сама по себе фича полезная. Code contracts отлично ловили такие ошибки на этапе компиляции. Но реализация — выглядит более чем сомнительно.
По стандарту языка — ссылочный тип или null или «что-то есть».
Нафига городить на уровне языка проверку «рук от бедер», тем более что сейчас компилятор не пропускает не проинициализированные переменные?
Всегда декларировалось, что интерфейс это декларация-контракт взаимодействия. Реализация — этим занимаются другие сущности.
А тут предлагают «улучшить» эти соглашения, только потому что кто-то «убил» множественное наследование классов, потому что это «будет сложно».
Может просто разрешить множественно наследование классов, чем так извращаться, причем ломая привычные соглашения?
или это очередной Vendor lock в исполнении M$?
У вас 15-летний код, и тут вдруг «Ай, ваш код шлак, у вас может быть null значение, срочно нужно переколбасить ваш код (вы же идиот и до сих пор об этом не подумали) или выключите нафиг наши предупреждения».
Нормальная адекватная логика.
Да и логика «не могут содержать null» подразумевает, что чем-то должна быть инициализирована переменная по умолчанию? Чем?
Отличная идея — сломать обратную совместимость по синтаксису.
Похожа на идею — значение True равно 0. Во где был фееричный треш на унаследованном коде.
Отличная идея, только кофеварку забыли приделать и пемзу для пяток…
В С++ уже лет 16 назад это не было проблемой. А в .Net это объяили «Злом», предали анафеме, а сейчас впихивают обратно. Правда почему-то ректально…
P.S.
Что они курят…
Недавно обнаружил, что мониторы Samsung S24H850QF*/S27H850QF* могу избразить что-то подобное:
― Поддерживается максимальное питание зарядки 45 Вт. Скорость зарядки зависит от ноутбука, подключенного к изделию.
Устройство можно использовать в качестве концентратора, подключив его к компьютеру с помощью кабеля USB Type-C. Можно напрямую подключить устройство-источник сигнала к монитору и управлять им с монитора, не подключая к компьютеру.
И
20V/3A, 12V/3A, 8V/3A, 5V/3A(Зависит от устройства)
В общем случае да. Булева алгебра — логическое сложение. Только при трактовке «это Int» будут интересные спецэффекты :)
Нет. Заставлять никто не будет. Просто при аресте чиновника распотрошат его мобилки, там найдут пару-тройку рабочих документов и добавят срок, дабы другим не повадно было.
Или возьмут пару чиновников, им отправят пару документов с грифом ДСП, потом эти документы найдут в публичном доступе/мобилках (вот Мегафон и оборудование закупает для закона Яровой). Публично накажут, и закон оправдают «вот смотрите какой полезный закон. педофила-наркомана не поймали, зато поймали чиновника-болтуна, который, как известно, находка для шпиона, потенциально шпиона террористов». И все в шоколаде.
Никого принуждать и не нужно будет. Сами с воем побегут покупать и пользоваться :)
Нашел таки описание в стандарте:
Глянул в 'WebAssembly Core Specification':
Так что насчет "… должен знать типы… если поменялось то обнаружить только тестами..." и тут ответ похоже «да должен знать» и «да только тестами проверить»
Тут согласен — не очень рационально использовать велосипед вместо уже сделанного и отпимизированного.
Опять же, зачем то сделали:
Не вижу проблем, при загрузке или компиляции генерить уникальные идентификаторы/хеши типов для быстрой проверки. Не парсить же описание типов каждый раз при каждом обращении.
Возможно Type.GUID Property уже служит для этих оптимизаций.
COM такой механизм опознавания типов использовал.
Это не новая идея и уже была реализована.
Не вижу смысла оспаривать документацию по .Net CLI VM:
и т.д. Там много такого люботыного.
Например открываем документацию для С++ и читаем:
если это все называется "… там нет механизмов защиты ..." боюсь тогда представить тогда что такое "… там есть механизмы защиты ..." :)
p.s.
Предлагаю пока закругляться с этим вопросом и возможно вернуться к нему позже :)
Стратегия строится на как можно раннем этапе предотвращения ошибок такими методами:
Это превентивный мехнизм, но он не помогает в процессе исполнения. В Runtime приходится применять другие механизмы. .Net предлагает свои механизмы, Java свои. А С++ например практически таких механизмов не предлагает и полагается в этом вопросе на разработчика.
Да. Это сработал один из защитных механизмов .Net в Runtime (проверил описание типов и цепочки наследования, согласно приведенным выше цитатам из стандартов для .Net). А на уровне спецификации языка «Object references are not blittable.» и соответсвующая ошибк компилятора: error CS0208: Cannot take the address of, get the size of, or declare a pointer to a managed type
Для С++ будет ошибка типа «Unhandled exception in BlaBlaBla.exe 0xC0000005 access violation» или «Unhandled exception at 0x7715A849 (ntdll.dll) in BlaBlaBla.exe: 0xC0000374: A heap has been corrupted (parameters: 0x77195910).» или еще черти что выпадет.
Сейчас с этим значительно лучше стало — средства разработки улучшились и «поумнели»