C# и перегрузка операторов - странный пример из Unity
В Юнити есть свой базовый класс Object (т.е. он не наследуется от дотнетовского Object) и такие перегруженные операторы дла него
public static bool operator ==(Object x, Object y);
public static bool operator !=(Object x, Object y);
public static implicit operator bool(Object exists);
С первыми двумя всё понятно, а вот третий странный. Он позволяет делать, например, такие проверки на существование объекта или равенства его null (смотри условие if):
MyClass myClassInstance; // MyClass type derives from Unity's Object or its descendants
if (!myClassInstance)
Вопрос. Даже если они написали свой базовый тип, но он же должен соответствовать спецификации C#, а там такого оператора нет. Насколько я знаю, можно перегружать существующие операторы, но не придумывать свои. Как они могли всё же добавить свой? Я не требую рассказать всё подробно, а просто ваши предположения. В Дотнете есть такие операторы и такие (это целый класс операторов, а не один конкретный), но нет bool-оператора.
Как некоторый минус - взамен этот Object не поддерживает операторы "?." и "??":
This class doesn't support the null-conditional operator (?.) and the null-coalescing operator (??).
Unity - Scripting API: Object (unity3d.com)
Я сначала расстроился, что хотя и версия C# 8.0, и версия Дотнета Standard 2.1, а всё равно опять придётся писать портянки с проверками
if(x != null)
вместо "?.", а потом только узнал, что в Юнити есть свой вариант.
Но минус в том, что в коде можно мешать объекты из двух разных имплементаций, и они будут поддедживать одни операторы и не поддерживать другие. Если человек не вкурсе, то не поймёт, что проихсодит. А для обычного шарписта это вновинку.
Вот ещё - у них и другие понятия Сишарпа и Дотнета не такие, как в оригиналах. Если в коде для Юнити объектов применять оператор "?.", то вам только warning выдадут, что он не применим.
Ну ладно Юнити - они уже большие и могут себе позволить местами плевать на стандарты. А если каждая дотнетовская библиотека начнёт свои правила устанавливать?
В Джаве тоже так? Т.е. в каждой имплементации (штуки 4 вроде уже как минимум сущесвтуют?) кучка своих подводных камней, которые чтобы все узнать, надо так годик покодить? Даже для базовых вещей. Т.е. я просто начинаю первые шаги делать, а мне говорят - наш район ничем от другого такого же не отличается. НО! В нашем районе начинают ходить всегда с левой ноги, и ступают только на пятку. За правую - штраф и падение производительности, а за полную стопу - утечка памяти. А так - вполне приличное место. Прикольно. ))
Впрочем, в оригинальном Шарпе тоже обзавелись своими предрассудками. Вот такие рекомендации видели? А ну бегом менять все свои "== null" и "!= null" на "is null", если ещё не сделали! Ведь кто-то же мог перегрузить "==" или "!="! Хорошо, что пока "is" нельзя, но если вдруг решат изменить...
Вообще, логика странная - типа нельзя вообще использовать перегружаемые операторы в "незнакомых классах", т.к. кто его знает, что там наперегружали. Нужно либо изучать исходники всех новых классов, либо не доверять им. Или все перегружаемые операторы продублировать неперегружаемыми... Интересно, как скоро они там захлебнутся в своей трясине?
В Юнити есть свой базовый класс Object
----
Начнем с простого
https://docs.microsoft.com/en-us/dotnet/api/system.object?...