Почему С# устанавливает частные переменные перед базовым конструктором, а VB.NET - наоборот?

Возник вопрос о сравнении кода С# и VB.NET, и результаты между кажущимся идентичным кодом были совершенно разными. (Я написал программу, которая позволяет двум классам "сражаться" . По какой-либо причине С# всегда выигрывает. Что случилось с VB.NET?)

Приведенное объяснение состоит в том, что С# инициализирует поля класса, а затем вызывает базовый конструктор, но VB.NET делает абсолютно противоположное.

Мой вопрос - почему?

Есть ли какая-то техническая причина для разных языков? На первый взгляд кажется, что любой подход одинаково важен, но я не могу понять, почему они не выбрали бы такой подход.

EDIT: Как отметил Jeffrey L Whitledge, у VB6 не было наследования, поэтому я не думаю, что мы можем сказать "держать VB.NET и VB6 более тесно связанными".

Ответ 1

Основной конструктор может выставить объект во внешний мир перед запуском конструкторов производного класса. Хотя часто следует избегать этого, есть моменты, когда это необходимо. Например, может быть два объекта, которые содержат ссылки друг на друга, и каждый объект может иметь в качестве инварианта класса, что ссылка на другой объект должна быть действительной. Для создания такой пары объектов требуется, чтобы один объект-конструктор передал частично сконструированный объект другому, или возвращал конструктор объекта до того, как его инварианты класса были удовлетворены.

Если инициализаторы полей производного класса не запускаются до тех пор, пока не будет запущен конструктор базового класса, и если конструктор базового класса предоставляет объект внешнему миру, это будет означать, что объект будет подвергаться внешнему миру перед любая инициализация производного класса имела место. Создателям С# не понравилась эта идея, поэтому они сделали инициализаторы производного класса перед конструктором базового класса.

С другой стороны, запуск инициализаторов производных классов перед конструктором базового класса имеет недостаток: эти инициализаторы не могут ссылаться на объект, находящийся в разработке. Также нет возможности использовать любые аргументы, переданные конструктору. Наличие частичной инициализации объекта до того, как управление передано конструктору базового класса, может быть приятным, но есть некоторые серьезные ограничения относительно того, как его можно инициализировать; может быть или не быть возможно, чтобы объект находился в полностью полезном состоянии до запуска базового конструктора.

Создатели vb.net, по-видимому, полагали, что поскольку запуск инициализаторов перед базовым конструктором не устраняет необходимость иметь дело с частично сконструированными объектами, подверженными внешнему миру, и поскольку он исключает использование некоторых полезных приемов, было бы лучше, чтобы инициализаторы запускались после базового конструктора. Это позволяет конструктору базового уровня выставлять один из его параметров в качестве поля, а затем использовать производный класс для значения этого поля в инициализаторах производного класса.

Возможно, подход С# позволяет делать вещи, которые нет в vb.net, но обратное неверно (можно было реализовать инициализаторы полей vb-стиля, просто записав поля в начале конструктора), С другой стороны, наличие декларации и инициализации поля рядом друг с другом более чистое, чем объявление в одном месте и инициализация где-то еще. Слишком плохо, ни один из языков не позволяет указать, что определенные определенные полевые декларации должны следовать противоположной парадигме из нормы.