none
Как запустить все using по умолчанию RRS feed

  • Вопрос

  • WPF C#

    У меня такая дилемма.

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

    Вообще в продолжении, зачем разбивка на using нужна? Это принципы ООП? Инкапсуляция?

    Лишние using в классе находясь память расходуют? Почему изначально не сделать подключение ко всем using, особенно моим, которые я создал сам в виде папок.

    3 ноября 2016 г. 16:49

Ответы

  • Самая очевидная (но не единственная) причина необходимости using  - в разных классах в глубине разных пространств имен могут вполне встречаться методы с одинаковыми называниями и что бы компилятор точно знал какой именно метод вы вызываете, вы должны обратится к нему по полному пути БлаБлаБла.БлаБла.Класс.НекийМедот или же добавить using и написать только НекийМедот. Одинаковые имена методов могут быть по разным причинам, таким как совместимость с прошлыми версиями, либо просто логичность названия.

    Ну это простым языком. А языком техническим - все написано здесь.

    Ну и на последок - абсолютно не вижу проблем в добавлении using в каждом новом файле. Это явно не тот случай, когда нужно автоматизировать и оптимизировать рабочий процесс.


    VB.Net - WPF, UWP

    3 ноября 2016 г. 17:57
    Отвечающий
  • Если слишком много объектов в одном пространстве имен, IntelliSence начинает работать медленно, да и вообще становится бесполезен, поскольку листать долгий список функций никто не хочет. Разбиение API на пространства имен - большое улучшение NET Framework по сравнению с со стандартным API где при включении одного windows.h 100500 функций в одном пространстве имен, и написать что-то в этом зоопарке можно только постоянно смотря в документацию. Без этого полноценная система визуальных подсказок никогда бы не зароботала.

    И да, конфликты есть. Даже в стандартных классах. Недавно перешел на WPF и обнаружил, что в классе окна по умолчанию подключается простанство имен с каким-то классом Path, который конфликтует с System.Io.Path

    Не расходуют они память (с чего вдруг? что добавляется значимого для среды выполнения? в объектный код включаются только реальные ссылки на используемые внешние объекты). Все равно не знаю, зачем вы хотите впихнуть все пространства имен. Ссылки на пространства имен в начале файла помогают быстро оценить, с какими библиотеками взаимодействует модуль. Явный плюс для тех кто будет читать код.

    3 ноября 2016 г. 19:12

Все ответы

  • Самая очевидная (но не единственная) причина необходимости using  - в разных классах в глубине разных пространств имен могут вполне встречаться методы с одинаковыми называниями и что бы компилятор точно знал какой именно метод вы вызываете, вы должны обратится к нему по полному пути БлаБлаБла.БлаБла.Класс.НекийМедот или же добавить using и написать только НекийМедот. Одинаковые имена методов могут быть по разным причинам, таким как совместимость с прошлыми версиями, либо просто логичность названия.

    Ну это простым языком. А языком техническим - все написано здесь.

    Ну и на последок - абсолютно не вижу проблем в добавлении using в каждом новом файле. Это явно не тот случай, когда нужно автоматизировать и оптимизировать рабочий процесс.


    VB.Net - WPF, UWP

    3 ноября 2016 г. 17:57
    Отвечающий
  • Если слишком много объектов в одном пространстве имен, IntelliSence начинает работать медленно, да и вообще становится бесполезен, поскольку листать долгий список функций никто не хочет. Разбиение API на пространства имен - большое улучшение NET Framework по сравнению с со стандартным API где при включении одного windows.h 100500 функций в одном пространстве имен, и написать что-то в этом зоопарке можно только постоянно смотря в документацию. Без этого полноценная система визуальных подсказок никогда бы не зароботала.

    И да, конфликты есть. Даже в стандартных классах. Недавно перешел на WPF и обнаружил, что в классе окна по умолчанию подключается простанство имен с каким-то классом Path, который конфликтует с System.Io.Path

    Не расходуют они память (с чего вдруг? что добавляется значимого для среды выполнения? в объектный код включаются только реальные ссылки на используемые внешние объекты). Все равно не знаю, зачем вы хотите впихнуть все пространства имен. Ссылки на пространства имен в начале файла помогают быстро оценить, с какими библиотеками взаимодействует модуль. Явный плюс для тех кто будет читать код.

    3 ноября 2016 г. 19:12