В этом коде класс C не должен откомпилироваться, потому что у него нет конструктора с параметрами int x, int y, а вот класс B откомпилируется без ошибок.
В C# класс С тоже не откомпилируется, он тоже обязан вызвать базовый конструктор через : base(..).
Возможен ещё один вариант: если в наследнике не перекрыт виртуальный конструктор предка, компилятор автоматически перекрывает его
Я не вижу ни одного плюса такой непонятной реализации.
А вот если у нас будут метаклассы, то код с неправильными параметрами просто не откомпилируется.
Все, что от C# требуется, это добавить Method<T>() where T : class. new (int, string), но мелкомягкие уже что-то вроде "сложно и не нужно" писали на этот счет.
Ну и стоит заметить что рефлексия это лишь инструмент для обучения, если нужно именно быстро и динамически создавать строго-типизированные классы, можно воспользоваться скомпилированными ExpressionTrees или даже прямой IL генерацией.
и самое главное, зачем вообще все мапперы нужны в приципе — это expression-based маппинг, шобы с БД тянуть инфу было удобненько, поэтому нужно обязательно это допилить
понятие правильности субъективно. но это еще не все, понятие правильности в контексте конкретной БД зависит только от конфигурации этой БД, а именно от сгенерированного этой самой БД плана выполнения запроса.
как думаете, существует ли query провайдер, умеющий собирать с БД несколько разных планов, для каждого конкретного linq-выражения, генерируя различные варианты sql запроса, а потом еще и определять правильность каждого?
это вопрос про настройку большого старого проекта. да, здесь единственный 100% точный вариант — это просмотреть код, чтобы знать, что nullable, а что нет. (хотя по хорошему уже бы иметь какие-то маркеры, комментарии там, или атрибуты, чтобы декоративно было все видно).
но если вы не хотите тратить время на подобную модернизацию большого и старого проекта, тогда зачем вы написали этот коммент?
но позвольте! а как вы раньше писали код, серьезно не задумываясь о том, что, в какой то конкретный момент, вот в этом вот месте, вы планируете возвращать null, и что вызывающий код должен сделать соответсвующую проверку? или вы просто по дефолту везде ThrowIfNull писали?
а что же касается "огромного количество фреймворков", то здесь ожидается полезность фунции только если конкретный фреймворк использовал это нововведение. скорее всего, MS введет атрибут [DontCheckForNullables] для референсов разных DLL.
Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.
Надо полагать, автор заодно захочет похвастаться знанием, как переопределить штатный QueryProvider у старого доброго Linq-2-Sql? Чтобы это добро все у меня заработало из коробки.
Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса
Не совсем ясен контекст вышего высказывания.
а) Индексировать VIEW можно только сделав его кластерным, и это уже не "на лету".
б) Так что ничто не мешает заранее проиндексировать стоблцы нужных таблиц для ожидаемого SELECT запроса "на лету".
Вообще-то индексация вполне себе возможна над любой проекцией, в том числе и Automapper-овской, при выполнении определенного условия.
В случае с постом, если бы требовалась индексация, единственным верным решением было бы создавать отдельную таблицу на каждый Enum.
В C# класс С тоже не откомпилируется, он тоже обязан вызвать базовый конструктор через
: base(..).Я не вижу ни одного плюса такой непонятной реализации.
Все, что от C# требуется, это добавить
Method<T>() where T : class. new (int, string), но мелкомягкие уже что-то вроде "сложно и не нужно" писали на этот счет.Ну и стоит заметить что рефлексия это лишь инструмент для обучения, если нужно именно быстро и динамически создавать строго-типизированные классы, можно воспользоваться скомпилированными ExpressionTrees или даже прямой IL генерацией.
я не особо в курсе, когда там уже можно будет полноценно писать на шарпе под браузер?
и самое главное, зачем вообще все мапперы нужны в приципе — это expression-based маппинг, шобы с БД тянуть инфу было удобненько, поэтому нужно обязательно это допилить
понятие правильности субъективно. но это еще не все, понятие правильности в контексте конкретной БД зависит только от конфигурации этой БД, а именно от сгенерированного этой самой БД плана выполнения запроса.
как думаете, существует ли query провайдер, умеющий собирать с БД несколько разных планов, для каждого конкретного linq-выражения, генерируя различные варианты sql запроса, а потом еще и определять правильность каждого?
а зачем нам лочиться на приватном объекте чужого класса?
но если выбирать между старыми проектами и новыми, то выбор очевиден
это вопрос про настройку большого старого проекта. да, здесь единственный 100% точный вариант — это просмотреть код, чтобы знать, что nullable, а что нет. (хотя по хорошему уже бы иметь какие-то маркеры, комментарии там, или атрибуты, чтобы декоративно было все видно).
но если вы не хотите тратить время на подобную модернизацию большого и старого проекта, тогда зачем вы написали этот коммент?
но позвольте! а как вы раньше писали код, серьезно не задумываясь о том, что, в какой то конкретный момент, вот в этом вот месте, вы планируете возвращать null, и что вызывающий код должен сделать соответсвующую проверку? или вы просто по дефолту везде ThrowIfNull писали?
а что же касается "огромного количество фреймворков", то здесь ожидается полезность фунции только если конкретный фреймворк использовал это нововведение. скорее всего, MS введет атрибут [DontCheckForNullables] для референсов разных DLL.
надеюсь они уберут этот бесполезный функционал
как это так? объясните. имхо, это же очень просто
интересно в каком языке все таки сделали полное математическое описание, с круглыми и квадратными скобками?
НЕЕЕЕ, НУ ТАК НЕ ИНТЕРЕСНО....
пожалуйста, будьте добры.
он в принципе не умеет работать с string.Format. а это именно то, во что разворачивается интерполирование.
штатный провайдер просто не умеет конвертировать вызовы к Format в нужную форму для обращения к БД
Ого, наконец-то годная статейка.
Надо полагать, автор заодно захочет похвастаться знанием, как переопределить штатный QueryProvider у старого доброго Linq-2-Sql? Чтобы это добро все у меня заработало из коробки.
И почему это плохо, иметь статичный, доступный отовсюду некий
GameState?эм, но в таком случае в статик кладется объект а-ля
AllStaticDataи обнуляется только он.Не совсем ясен контекст вышего высказывания.
а) Индексировать VIEW можно только сделав его кластерным, и это уже не "на лету".
б) Так что ничто не мешает заранее проиндексировать стоблцы нужных таблиц для ожидаемого SELECT запроса "на лету".
Вообще-то индексация вполне себе возможна над любой проекцией, в том числе и Automapper-овской, при выполнении определенного условия.
В случае с постом, если бы требовалась индексация, единственным верным решением было бы создавать отдельную таблицу на каждый Enum.