Углубление в C#
Страница 6. Пространства имен в C# и Java

Хейлсберг: Концептуально да, но их реализации вовсе не похожи. В Java имена пакетов имеют также и физический смысл, который указывает на структуру директорий ваших исходных файлов. В C# мы имеем полное разделение между физическим расположением и логическим именованием, так, если вы вызовете ваше пространство имен, то ничего не произойдет в реальном физическом хранилище вашего кода. Это дает вам свободу располагать модули вместе в физических пакетах, не принуждая вас иметь соответствие в директориях. В самом языке, конечно, тоже существуют отличия. Так как в Java пакеты имеют также и физическую структуру, исходный файл должен располагаться в верной директории и иметь только один public класс или public тип. В виду того, что в C# нет такой связи физического и логического расположения, вы можете именовать свои исходные файлы как захотите. В каждом файле может содержаться несколько пространств имен и несколько public классов. Таким образом вы можете записать весь ваш исходный код в один файл или расположить его в нескольких маленьких. Концептуально во время компиляции происходит следующее - вы передаете все исходные файлы вашего проекта компилятору, а он уже решает что с ними делать.

Осборн: У меня есть вопрос о настраиваемом программировании: Вы считаете, что это важная концепция и она должна быть частью объектно ориентированного языка. Если это так, то каковы ваши планы реализацию настраимового программирования, как части C#.

Гудхью: Кое-что из того, что мы собирались включить в первый релиз, было создано - вопреки тому, что все думают о Microsoft - у нас нет неограниченных ресурсов. Мы приняли несколько трудных решений о том, что действительно будет в первом релизе.

Хейлсберг: В отношении настроек, о которых вы спрашивали - Я определенно думаю, что это очень полезная концепция. Нужно отметить что все исследования настроек происходили в академии и индустрии. Шаблоны - решение для этой проблемы. Во время наших внутренних обсуждений мы решили, что хотели бы включить это в нашу новую платформу. Чего мы действительно хотим - чтобы среда выполнения понимала настройки. Это отличается от того, как некоторые прототипы настроек были построены. Возьмите понятие стирания (erasure) в Java, в действительности у системы нет никаких представлений о настройках. Имея понимание концепции настроек, как в CLR, множество языков могут добиться большей функциональности. Вы можете писать на C# настраиваемый класс, а другой человек в другом месте будет работать с ним, используя другой язык.

Добавление настроек в среду выполнения, позволит вам делать некоторые вещи намного эффективнее. Установку настроек лучше всего производить во время выполнения. В C++, установка шаблонов происходила во время компиляции, а далее у вас было два варианта: или оставить свой код раздутым, или попытаться избавиться от раздутости во время компоновки. Но если у вас есть несколько приложений, вы можете забыть об этом. У вас просто будет раздутый код.

Добавив понятие настроек в общую среду выполнения, она стала понимать, что когда приложение или компонент запрашивают у нее список всех "Foo", оно задает себе вопрос "Имею ли я на данный момент реализацию (код, создающийся при вызове настраиваемой функции, в зависимости от параметров) списка Foo?". Если это так, использует его. Так, если Foo тип, передаваемый по ссылке, то реализация может быть одна для всех ссылочных типов. Если же тип, передаваемый по значению (вроде int или float) - то для каждого типа будет своя реализация. Но только тогда, когда приложение запрашивает ее. Мы проделали всю основную работу, необходимую для добавления распознавания настроек в среду выполнения.

Интересна связь между IL и распознаванием настроек. Если инструкции в IL содержат информацию о типах, например, если сложение это не сложение, а сложение int, сложение float или сложение double - у вас нет возможности настроек в таком случае. Наш формат IL вправду нейтрален к типам. И по причине нейтральности к типам, мы можем добавить возможность настроек позже, без каких-либо для нас проблем. Это одна из причин, почему наш IL выглядит иначе, нежели Java байткод. Он у нас нейтрален к типам. И инструкция сложение - это сложение двух элементов, находящихся вверху стэка. Это может быть преобразовано в иной код, когда настройки будут реализовываться.

Осборн: Это доступно во всех языках платформы .NET?

Хейлсберг: Да. Исследовательский центр Microsoft Research в Кэмбридже создала версии общей среды выполнения и компилятора C#, допускающие настройки. Мы ищем путь внедрения этого. Похоже что этого не произойдет в первом релизе. Но мы сейчас работаем над тем, чтоб убедиться, что не делаем каких-либо вещей в первом релизе, которые не восприняли бы картины настроек.

Осборн: Когда вы планируете выпустить C#, платформу .NET и следующую версию Visual Studio?

Гудхью: Мы уже раздали здесь обзорную версию технологии 6500 посетителям конференции. Мы собираемся некоторое время (2000 год) использовать beta версию, а далее, когда все будет готово, сделаем релиз. Одна из вещей, которую мы действительно проделали - это подробный анализ, того, как прошел релиз Windows 2000, и путей вовлечения некоторых клиентов в процесс разработки и распространения. В случае платформы .NET и Visual Studio, мы будем вновь работать с клиентами, чтобы понять, когда все это действительно будет готово к релизу. Пусть они скажут нам, когда продукт готов. И по причине того, что в процесс вовлечены реальные клиенты, продукт обещает быть качественным. Другой стороной этого процесса является приобретение некой неопределенности. Мы ориентируемся на качество продукта, а не просто выбираем дату выпуска.

Осборн: Таким образом дату, когда будет написан весь код, вы заменяете датой, когда продукт будет готов работать?

Гудхью: Да это так. Я думаю, что разработчики узнают релиз Visual Studio .NET, как один из наиболее качественных релизов за всю историю Microsoft.