Почему пространство имен консоли необходимо импортировать в проект приложения консоли

Если я создаю новое консольное приложение, тогда это компилируется нормально:

Module Module1

    Sub Main()
        Console.ReadKey()
    End Sub

End Module

Альтернативой является следующее:

Imports System.Console
Module Module1

    Sub Main()
        ReadKey()
    End Sub

End Module

Я не понимаю now , так как это консольное приложение, почему эти проекты не созданы таким образом, что следующее будет компилироваться ?:

Module Module1

    Sub Main()
        ReadKey()
    End Sub

End Module

Put another way: if it is a Console app why do I need to import the Console namespace?

Это то же поведение, что и при использовании приложения winForms , я говорю Me.someControl ? Хотя в этой ситуации я могу оставить Me , и он все равно будет компилироваться без импорта пространства имен форм.

<�Сильный> ИЗМЕНИТЬ

Imports System.Console
Module Module1

    Sub Main()
        ReadKey()
        Console.ReadKey()  '<

ДАЛЬНЕЙШЕЕ ИЗОБРАЖЕНИЕ

Ганс предложил дальнейшее поведение и повторить это, я имею следующее:

Я добавил новый ClassLibrary1 к тому же Solution , как это ...

enter image description here

В Console ConsoleSandpit у меня есть следующее, со ссылкой на ClassLibrary1 , как ...

enter image description here

... только проблема в том, что я ожидаю ошибку компиляции из выше, но, похоже, работает нормально!

1
добавлено отредактировано
Просмотры: 1
de
для разных объектов будут доступны разные функции, но я полагаю, что эти функции могут иметь одно и то же имя, например, ObjectX.functionA , а также ObjectY.functionA . Но если вы уже используете внутри консольное приложение, кажется странным, что консоль должна быть явно указана; хотя я полагаю, что это похоже на выражение Me.X , когда внутри проекта winforms ?
добавлено автор whytheq, источник
Иными словами: зачем существуют пространства имен any ? Почему бы не использовать все функции без каких-либо пространств имен или префиксов?
добавлено автор Damien_The_Unbeliever, источник

3 ответы

System.Console is not a namespace. ReadKey is a shared method in the Console class which is in the System namespace

Итак, разбивка следующего утверждения такова:

System.Console.ReadKey()
  • System - Namespace
  • Console - Class
  • ReadKey - Shared method

Таким образом, когда вы вызываете Console.ReadKey() (без указания пространства имен), вы обычно должны будете импортировать System в начало вашего файла кода. Однако это необязательно, потому что в проектах VB.NET вы можете указать список пространств имен по умолчанию, которые автоматически импортируются для всех файлов проекта. Вы можете изменить их, используя контрольный список пространств имен по умолчанию в своем дизайне свойств проекта. System , в частности, автоматически импортируется как пространство имен по умолчанию со всеми шаблонами проектов.

Как вы продемонстрировали в своем вопросе, в VB.NET можно импортировать имя класса или модуля. Оператор Imports не ограничивается просто работой с пространствами имен. Однако, насколько мне известно, нет способа импортировать имя класса с параметром namespaces по умолчанию для проекта (или, по крайней мере, не с дизайнером свойств проекта, так или иначе).

Если System.Console было пространством имен, я согласен с тем, что вы ожидаете, что шаблон проекта для консольных проектов будет импортировать это пространство имен по умолчанию. Однако, поскольку это не пространство имен вообще, вы не ожидаете, что это сделает это :)

2
добавлено
может потребоваться отметить это, чтобы нажать на вас более 10 000!
добавлено автор whytheq, источник
вы получили один из тех поздравительных экранов с множеством мигающих огней и фейерверков?
добавлено автор whytheq, источник
вы можете увидеть ДАЛЬНЕЙШЕЕ ИЗОБРАЖЕНИЕ Я добавил к OP? Почему этот сценарий скомпилирован? То, что я пытаюсь сделать в ДАЛЬНЕЙШЕМ РЕДАКТИРОВАНИИ, повторяет сценарий, который Ганс упомянул в своем ответе - что я делал неправильно?
добавлено автор whytheq, источник
эй Стив - вы когда-нибудь импортировали System.Console ? или вы просто импортируете пространство имен System , а затем в свой код напишите Console.xxx ? Более читаемо, чтобы на самом деле включить в консоль слово «Консоль»?
добавлено автор whytheq, источник
отлично - вы подтвердили, что я думал.
добавлено автор whytheq, источник
Эй Стив - ты когда-нибудь играл с VBA ? См. этот пост
добавлено автор whytheq, источник
Woohoo! В заключение! Благодаря :)
добавлено автор Steven Doggart, источник
Я не могу воспроизвести точный характер, который описывает Ханс. Самое близкое, что я могу найти, это создать библиотеку классов с помощью этого метода, и вы намереваетесь вызвать метод THAT, вы не можете сделать это легко, если у вас есть Imports System.Console в верхней части ваш файл. В противном случае, все это компилируется для меня тоже, поэтому я не уверен, что он имеет в виду, в частности.
добавлено автор Steven Doggart, источник
Я никогда не импортирую имена классов. Я нахожу это запутанным. На самом деле мне кажется, что это раздражает, что имена модулей всегда импортируются по умолчанию. Но, насколько это нормально? Я бы сказал, что я никогда не видел импорта System.Console . Каждый раз, когда я видел или работал с кодом проекта консоли, код всегда предшествует всем вызовам методов Console с именем класса.
добавлено автор Steven Doggart, источник
К сожалению (или, к счастью, для меня), у меня нет опыта работы с VBA, поэтому мне жаль говорить, что я не могу помочь вам в этом ...
добавлено автор Steven Doggart, источник

Добавьте проект библиотеки классов в ваше решение и вставьте этот код:

Module FooBar
    Sub ReadKey(ByVal wait As Integer)
    End Sub
End Module

И наблюдайте, как вдруг ваш исходный код не удается скомпилировать. С серьезным тупым сообщением об ошибке: «Аргумент не указан для параметра« wait ». Вы можете потерять часы своей жизни, пытаясь понять, почему Console.ReadKey() хочет аргумент wait .

1
добавлено
+1 подозреваю, что я не правильно следую вашим инструкциям. Ганс, как и я, по-прежнему компилируется. Могу ли я отредактировать сообщение с моей попыткой следовать этим инструкциям - вы можете переделать правильные шаги?
добавлено автор whytheq, источник
Нет Ганс - я новичок, который интересуется тем, о котором вы мне рассказываете, но у меня возникают проблемы с его тиражированием - я отредактирую свой OP с помощью шагов, которые я пройду, - может быть, вы сможете просмотреть их и сказать мне что я делаю неправильно?
добавлено автор whytheq, источник
Я тестировал этот сценарий перед публикацией. Я сомневаюсь, что вы улучшите его, редактируя.
добавлено автор Hans Passant, источник

1) В консольном приложении вы можете делать много полезных вещей, во многих функциях, не требуя или не нуждающихся в фактическом взаимодействии с Console .

2) Я мог бы легко представить себе функцию, называемую ReadKey , которая выдает небольшое приглашение для нажатия одной или двух клавиш - на основе ввода пользователя, если его один из этих ключей, верни это. В противном случае укажите ошибку и повторите запрос. Почему мне нужно выбрать другое имя для этой функции, потому что мое собственное пространство имен было автоматически загрязнено методами из Console ?

Пространства имен существуют, чтобы помочь разделить и организовать функциональность. Вам предоставляются параметры (например, оператор Imports ), чтобы скрыть эти разделения, где имеет смысл вы в приложении , но я не хотел бы, чтобы это принудительно использовалось для пользователей all .

1
добавлено
... import , похоже, не помогает, если я создаю функцию ReadKey - мне тогда нужно явно писать Console.ReadKey , если я хочу для использования функции readKey в консоли, связанной с моей функцией
добавлено автор whytheq, источник