использование using
От: Mamut Швеция http://dmitriid.com
Дата: 15.10.02 16:25
Оценка:
простите, а разве использование using namespace.namespace2 не будет аналогично #include <something.h>?


dmitriid.comGitHubLinkedIn
Re: абсолютно нет
От: jazzer Россия Skype: enerjazzer
Дата: 15.10.02 21:52
Оценка: 3 (1) :)
Здравствуйте Mamut, Вы писали:

M>простите, а разве использование using namespace.namespace2 не будет аналогично #include <something.h>?


начать с того, что #include — это директива препроцессора, а using — инструкция.

директива #include производит обычную тупую текстовую подстановку вместо себя содержимого файла, который указан в скобочках.

так что
#include <something.h>
будет аналогичен
using namespace namespace2;
только в том случае, если содержимое файла something.h состоит только из одной строчки
using namespace namespace2; // :))
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[2]: абсолютно нет
От: Mamut Швеция http://dmitriid.com
Дата: 17.10.02 16:45
Оценка:
Здравствуйте jazzer, Вы писали:

J>Здравствуйте Mamut, Вы писали:


M>>простите, а разве использование using namespace.namespace2 не будет аналогично #include <something.h>?


J>начать с того, что #include — это директива препроцессора, а using — инструкция.


J>директива #include производит обычную тупую текстовую подстановку вместо себя содержимого файла, который указан в скобочках.


J>так что

J>
J>#include <something.h>
J>
будет аналогичен

J>
J>using namespace namespace2;
J>
только в том случае, если содержимое файла something.h состоит только из одной строчки

J>
J>using namespace namespace2; // :))
J>



а что же в таком случае делает using даже если это и инструкция?. Разве это не то же указание компилятору что и откуда использовать?


dmitriid.comGitHubLinkedIn
Re[3]: абсолютно нет
От: retalik www.airbandits.com/
Дата: 18.10.02 07:03
Оценка:
Здравствуйте Mamut, Вы писали:

M>а что же в таком случае делает using даже если это и инструкция?. Разве это не то же указание компилятору что и откуда использовать?


Мы все еще о C++ говорим? Тогда using служит только для указания области видимости объектов пространства имен.
Например, после
using Foo::Bar;

можно будет вместо Foo::Bar писать просто Bar.
Почитай про ключевое слово namespace.
Успехов,
Виталий.
Re[4]: абсолютно нет
От: Mamut Швеция http://dmitriid.com
Дата: 22.10.02 06:06
Оценка:
Здравствуйте retalik, Вы писали:

R>Здравствуйте Mamut, Вы писали:


M>>а что же в таком случае делает using даже если это и инструкция?. Разве это не то же указание компилятору что и откуда использовать?


R>Мы все еще о C++ говорим? Тогда using служит только для указания области видимости объектов пространства имен.

R>Например, после
R>
R>using Foo::Bar;
R>

R>можно будет вместо Foo::Bar писать просто Bar.
R>Почитай про ключевое слово namespace.

нет, я про языки типа C#, где довольно сильно рекламируется отсутствие директив #include. зато в примерах, что я видел, отсутствие директив неплохо восполняется кучей using'ов


dmitriid.comGitHubLinkedIn
Re[5]: абсолютно нет
От: retalik www.airbandits.com/
Дата: 22.10.02 06:37
Оценка:
Здравствуйте Mamut, Вы писали:

M>нет, я про языки типа C#, где довольно сильно рекламируется отсутствие директив #include. зато в примерах, что я видел, отсутствие директив неплохо восполняется кучей using'ов

Нет, и в C# это не так.
Директива using (Imports в VB.NET) всего-навсего определяет видимость в пространстве имен. Для указания "откуда что брать" используется директива компилятора /reference (/r). Просто mscorlib линкуется по умолчанию.
Успехов,
Виталий.
Re[5]: абсолютно нет
От: Аноним  
Дата: 22.10.02 09:42
Оценка:
Здравствуйте Mamut, Вы писали:


M>нет, я про языки типа C#, где довольно сильно рекламируется отсутствие директив #include. зато в примерах, что я видел, отсутствие директив неплохо восполняется кучей using'ов


Правильно уже сказали — это совершенно разные вещи. Это просто импорт пространства имен. Просто для удобства. Есть два варианта:
1. myNamespace.MyClass.xxx
2. using myNamespace
...
MyClass.xxx

В обоих случаях байт код идентичен. Если не лень печатать долго — можно и без using. #include же вставляет код — т.е. полученный код будет освершенно другим.
Re[5]: абсолютно нет
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.10.02 10:35
Оценка:
Здравствуйте Mamut, Вы писали:

M>нет, я про языки типа C#, где довольно сильно рекламируется отсутствие директив #include. зато в примерах, что я видел, отсутствие директив неплохо восполняется кучей using'ов


Там тоже using реально никаких действий не производит, просто задает компилятору где искать классы у которых namespace не указан.
... << RSDN@Home 1.0 alpha 12 (developer build)>>
AVK Blog
Re: Да, аналогично
От: Рек Россия  
Дата: 23.10.02 17:37
Оценка:
Здравствуйте Mamut, Вы писали:

M>простите, а разве использование using namespace.namespace2 не будет аналогично #include <something.h>?


Все вы конечно всё абсолютно правильно говорите.

Но всё-таки по смыслу, а не формально,
действие #include аналогично using.

Поясняю:

С++
Файл A.h это интерфейс модуля A.cpp
#include "A.h" это объявление о том, что модуль А будет использован здесь.

С#
using XXX.A; это тоже самое, это выражение намерения использовать
пространство имён XXX.A (читай модуль), что на 90% совпадает с намерением использовать
конкретную сборку (на 10% — конкретный набор сборок).

Механизм того, как работает это объявление — не важен.
В С++ и в C# он разный, ну и что?
На логическом уровне эти объявления одинаковы.
Смысл их одинаков — использование одного модуля другим
(зависимость одного модуля от другого).

Конечно это всё не формальные правила.
Но полезная практика.
Так удобно (думать), только и всего.

Кстати чтобы эта практика работала, не стоит в C# без нужды
использовать полные имена типов.
Так же как в C++ не стоит писать в cpp ручками прототипы функций,
вместо включения хидеров.

Re[2]: Да, аналогично
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.10.02 18:02
Оценка:
Здравствуйте Рек, Вы писали:

Рек>С++

Рек>Файл A.h это интерфейс модуля A.cpp
Рек>#include "A.h" это объявление о том, что модуль А будет использован здесь.

Использован в любом случае. И не только интерфейс. Главное — компилятор парсит дополнитльный исходник и выходной еод при этом меняется.
И еще — инклюд указывает на реальный файл — 1 инклюд 1 файл. А вот неймспейс может быть как 1 на несколько сборок, так и несколько спейсов в одной сборке.

Рек>С#

Рек>using XXX.A; это тоже самое, это выражение намерения использовать
Рек>пространство имён XXX.A (читай модуль), что на 90% совпадает с намерением использовать
Рек>конкретную сборку (на 10% — конкретный набор сборок).

Ничего подобного.

Рек>Механизм того, как работает это объявление — не важен.


Это не объявление. Это примерно тоже что #pragma в плюсах.

Рек>На логическом уровне эти объявления одинаковы.


Абсолютно различны. Практически ничего общего.

Рек>Смысл их одинаков — использование одного модуля другим

Рек>(зависимость одного модуля от другого).

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

Рек>Конечно это всё не формальные правила.

Рек>Но полезная практика.

Очень вредная

Рек>Так удобно (думать), только и всего.


Не знаю на счет удобства, но вредно точно.

Рек>Кстати чтобы эта практика работала, не стоит в C# без нужды

Рек>использовать полные имена типов.

Без нужды конечно не стоит. Но писать юзинг ради единственного места где встречается этот неймспейс тоже не стоит.
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
Re[3]: Да, аналогично
От: Рек Россия  
Дата: 23.10.02 20:21
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Рек, Вы писали:


Рек>>С++

Рек>>Файл A.h это интерфейс модуля A.cpp
Рек>>#include "A.h" это объявление о том, что модуль А будет использован здесь.

AVK>Использован в любом случае. И не только интерфейс. Главное — компилятор парсит дополнитльный исходник и выходной еод при этом меняется.


Да. Все правильно.
Но ты всё про механизм говоришь, а я про смысл.

AVK>И еще — инклюд указывает на реальный файл — 1 инклюд 1 файл. А вот неймспейс может быть как 1 на несколько сборок, так и несколько спейсов в одной сборке.


Да. Это так.
Наверное модулем в .Net надо считать неймспейс, а не сборку.
А то что неймспейс физически разбит на сборки — это не так важно.
Болееменее цельный логически кусок кода (модуль) — это наверное неймспейс.

Рек>>С#

Рек>>using XXX.A; это тоже самое, это выражение намерения использовать
Рек>>пространство имён XXX.A (читай модуль), что на 90% совпадает с намерением использовать
Рек>>конкретную сборку (на 10% — конкретный набор сборок).

AVK>Ничего подобного.


80/20 или 99/1 ?

Рек>>Механизм того, как работает это объявление — не важен.


AVK>Это не объявление. Это примерно тоже что #pragma в плюсах.


Не понял. Ты про какие #pragma ?

Рек>>На логическом уровне эти объявления одинаковы.


AVK>Абсолютно различны. Практически ничего общего.


Рек>>Смысл их одинаков — использование одного модуля другим

Рек>>(зависимость одного модуля от другого).

AVK>Нет, using не устанавливает зависимостей. Зависимости устанавливает компилятор на основании явно затребованных в коде классов. На юзинги при этом ему начхать.



Да, using не устанавливает зависимостей, но он их обозначает,
подсказывает, помогает их видеть програмисту.
(если разумно использовать конечно)

Рек>>Конечно это всё не формальные правила.

Рек>>Но полезная практика.

AVK>Очень вредная


Рек>>Так удобно (думать), только и всего.


AVK>Не знаю на счет удобства, но вредно точно.


Мне помогает лучше видеть структуру программы,
помогает наводить порядок (относительный конечно .

А чем вредно кстати ?

Немного дополнительной дисциплины,
в обмен на доп помощь со стороны компилятора.
Что тут вредного?

Рек>>Кстати чтобы эта практика работала, не стоит в C# без нужды

Рек>>использовать полные имена типов.

AVK>Без нужды конечно не стоит. Но писать юзинг ради единственного места где встречается этот неймспейс тоже не стоит.


Вот тут не согласен. Стоит.
Ты что же, если тебе нужна только одна функция CreateWindow,
не подключаешь windows.h ? А выкусываешь один прототип и вставляешь
его к себе в сишник? Использовать длинное считай тоже самое.

Нет. Наверное бывают безвыходные случаи. Конфликты имён...
Хотя в этом случае можно использовать using с заданием синонима!
И опять всё будет хорошо.
Re[4]: Да, аналогично
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.10.02 20:50
Оценка:
Здравствуйте Рек, Вы писали:

Рек>Да. Все правильно.

Рек>Но ты всё про механизм говоришь, а я про смысл.

Бытие поределяет сознание

Рек>Да. Это так.

Рек>Наверное модулем в .Net надо считать неймспейс, а не сборку.

Ни в коей мере. Неймспейс это неймспейс и есть, т.е. пространство имен, ничего более.

Рек>А то что неймспейс физически разбит на сборки — это не так важно.


Важно. Неймспейс вобще физически не существует, есть только full qualified class names, совокупность которых и образует эти самые неймспейсы, состав которых зависит от набора этих самых классов. И задача определения всех классов входящих в какой то нейспейс теоретически не имеет решения.

Рек>Болееменее цельный логически кусок кода (модуль) — это наверное неймспейс.


Нет. Неймспейс это абстракция. Логически завершенный кусок кода это класс.

Рек>>>using XXX.A; это тоже самое, это выражение намерения использовать

Рек>>>пространство имён XXX.A (читай модуль), что на 90% совпадает с намерением использовать
Рек>>>конкретную сборку (на 10% — конкретный набор сборок).

AVK>>Ничего подобного.


Рек>80/20 или 99/1 ?


Ни то ни то. При желании вобще можно юзинг не использовать.

AVK>>Это не объявление. Это примерно тоже что #pragma в плюсах.

Рек>Не понял. Ты про какие #pragma ?

Хинты компилеру.

AVK>>Нет, using не устанавливает зависимостей. Зависимости устанавливает компилятор на основании явно затребованных в коде классов. На юзинги при этом ему начхать.


Рек>Да, using не устанавливает зависимостей, но он их обозначает,


Не обозначает. Он вобще никакого отношения к кросссборочным рефренсам не имеет.

Рек>подсказывает, помогает их видеть програмисту.


Это уже от лукавого. Все равно если список юзингов вырастает больше 10-20 наименований никто в голове их уже не удержит. Так что с точки зрения читаемости для редко используемых неймспейсов лучше как раз юзинги не писать.

AVK>>Не знаю на счет удобства, но вредно точно.


Рек>Мне помогает лучше видеть структуру программы,


Опыт мешает. От этого потом начинают появлятся вопросы вроде "как сделать чтобы класс автоматически регистрировался".
Вобще — механизм линковки и загрузки классов в CLR один из важнейших и по моему мнению схему его работы должен знать любой программист.

Рек>Немного дополнительной дисциплины,

Рек>в обмен на доп помощь со стороны компилятора.
Рек>Что тут вредного?

Никакой дисциплины я здесь не вижу. Вот наткнулся человек при изучении твоей программы на некий класс из редко используемого неймспейса. Если явно указан неймспейс прямо на месте то сразу понятно что это и откуда. А если нет то приходиться лезть в начало файла и просматривать юзинги и гадать — к какому из них относиться искомый класс.
И еще один момент — чем больше юзингов тем выше вероятность конфликтов имен, которые в свою очередь могут привести к трудновылавливаемым глюкам. Ну и компиляция замедляется.


AVK>>Без нужды конечно не стоит. Но писать юзинг ради единственного места где встречается этот неймспейс тоже не стоит.


Рек>Вот тут не согласен. Стоит.

Рек>Ты что же, если тебе нужна только одна функция CreateWindow,
Рек>не подключаешь windows.h ? А выкусываешь один прототип и вставляешь
Рек>его к себе в сишник? Использовать длинное считай тоже самое.

Ты издеваешься? Я тебе ввесь топик доказываю что хидеры и юзинг это принципиально разные вещи — а ты опять туда же? Вот тебе ответ на вопрос чем вредно — мыслишь в старых терминах и делаешь ошибочные выводы.
А пример немножко некорректен — если нужна CreateWindow то скорее всего из windows.h будет нужно много чего еще. Если же я уверен что кроме CreateWindow я точно не буду ничего использовать то таки да — опишу в своем хидере чем подключать монстра вроде windows.h.

Рек>Хотя в этом случае можно использовать using с заданием синонима!


Да, это особо способствует читаемости кода, еще и алиасы в голове держать.

Рек>И опять всё будет хорошо.


Хорошо будет только при правильном понимании механизмов работы.
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
Re[2]: Да, аналогично
От: Ved Украина  
Дата: 24.10.02 06:24
Оценка:
Здравствуйте Рек, Вы писали:

Рек>Все вы конечно всё абсолютно правильно говорите.


Рек>Но всё-таки по смыслу, а не формально,

Рек>действие #include аналогично using.


Вот уж дискуссия разгорелась... А ведь кроме директивы препроцессора using есть еще другой using — который определяет границы использования объекта(который обязательно должен поддерживать для этого IDisposable) и где он будет разрушен —
например, код

//.... тут был какой-то код
using(MyObject obj = new MyObject())
{
   obj.SomeProperty = SomeValue;
   obj.MyMethod(AnotherSomeValue);
}

будет аналогичен следующему коду
MyObject obj = new MyObject()
try
{
   obj.SomeProperty = SomeValue;
   obj.MyMethod(AnotherSomeValue);
}
finally
{
   obj.Dispose();
}


И использование using в данном случае делает код более читабельным. Если же объект не содержит в дереве наследования IDisposable, то тогда using уже не поиспользуешь...
Re[3]: Да, аналогично
От: Аноним  
Дата: 24.10.02 06:54
Оценка:
Здравствуйте Ved, Вы писали:

Ved>И использование using в данном случае делает код более читабельным. Если же объект не содержит в дереве наследования IDisposable, то тогда using уже не поиспользуешь...


Using 'using' is usually unusable .
Re[3]: Да, аналогично
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.10.02 07:29
Оценка:
Здравствуйте Ved, Вы писали:

Ved>Вот уж дискуссия разгорелась... А ведь кроме директивы препроцессора using есть еще другой using — который определяет границы использования объекта(который обязательно должен поддерживать для этого IDisposable) и где он будет разрушен —


Это юзинг называется using statement, а тот о котором речь using directive
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
Re[5]: Да, аналогично
От: Рек Россия  
Дата: 24.10.02 08:58
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Рек, Вы писали:

Рек>>Да. Все правильно.
Рек>>Но ты всё про механизм говоришь, а я про смысл.
AVK>Бытие поределяет сознание :)
Рек>>Да. Это так.
Рек>>Наверное модулем в .Net надо считать неймспейс, а не сборку.
AVK>Ни в коей мере. Неймспейс это неймспейс и есть, т.е. пространство имен, ничего более.

Конечно ты прав.
Но моё предложение сводится к тому, что бы придать неймспейсам доп. смысл.
В споре выкристализовалась такая позиция:

Считать неймспейс модулем,
а using считать объявлением об использовании этого модуля.
(неймспейсы организованы иерархически, и модули тоже, это нормально).

Чтобы такой взгляд был не противоречив, надо придерживаться доп ограничений при программировании — не использовать полные имена типов, а исползовать короткие или синонимы неймспейсов.

Это всё.

Рек>>А то что неймспейс физически разбит на сборки — это не так важно.

AVK>Важно. Неймспейс вобще физически не существует, есть только full qualified class names, совокупность которых и образует эти самые неймспейсы, состав которых зависит от набора этих самых классов. И задача определения всех классов входящих в какой то нейспейс теоретически не имеет решения.

Да! Неймспейс физически не существует.
Но я предлагаю способ работы на логическом уровне.


Рек>>Болееменее цельный логически кусок кода (модуль) — это наверное неймспейс.

AVK>Нет. Неймспейс это абстракция. Логически завершенный кусок кода это класс.

.Net не позволяет объявить об использовании класса.
Только об неймспейсе.
Разве это не аргумент в пользу того, что неймспейсы это и есть модули?!


Рек>>>>using XXX.A; это тоже самое, это выражение намерения использовать

Рек>>>>пространство имён XXX.A (читай модуль), что на 90% совпадает с намерением использовать
Рек>>>>конкретную сборку (на 10% — конкретный набор сборок).
AVK>>>Ничего подобного.
Рек>>80/20 или 99/1 ?
AVK>Ни то ни то. При желании вобще можно юзинг не использовать.
Я имел в виду, что 90% пространств имён умещается в одной сборке.

AVK>>>Это не объявление. Это примерно тоже что #pragma в плюсах.

Рек>>Не понял. Ты про какие #pragma ?
AVK>Хинты компилеру.

Ты про #pragma ... lib ? Совсем нет.
Думаю надо постараться сделать using более похожим на паскалевский use.


AVK>>>Нет, using не устанавливает зависимостей. Зависимости устанавливает компилятор на основании явно затребованных в коде классов. На юзинги при этом ему начхать.

Рек>>Да, using не устанавливает зависимостей, но он их обозначает,
AVK>Не обозначает. Он вобще никакого отношения к кросссборочным рефренсам не имеет.
Рек>>подсказывает, помогает их видеть програмисту.
AVK>Это уже от лукавого. Все равно если список юзингов вырастает больше 10-20 наименований никто в голове их уже не удержит. Так что с точки зрения читаемости для редко используемых неймспейсов лучше как раз юзинги не писать.

(*)
На это отвечу так. Если зашкаливют юзинги, то это значит,
что неправильно побит код на классы. Т.е всё свалено в кучу (всё использует всё).
При правильной структуре классов юзинги будут в файле тольно те, что
относятся к теме класса, их не бывает много (тк тем у класса не много),
а потому понятие "редкоиспользуемый" будет не актуальным.

AVK>>>Не знаю на счет удобства, но вредно точно.

Рек>>Мне помогает лучше видеть структуру программы,
AVK>Опыт мешает. От этого потом начинают появлятся вопросы вроде "как сделать чтобы класс автоматически регистрировался".
AVK>Вобще — механизм линковки и загрузки классов в CLR один из важнейших и по моему мнению схему его работы должен знать любой программист.
Рек>>Немного дополнительной дисциплины,
Рек>>в обмен на доп помощь со стороны компилятора.
Рек>>Что тут вредного?
AVK>Никакой дисциплины я здесь не вижу. Вот наткнулся человек при изучении твоей программы на некий класс из редко используемого неймспейса. Если явно указан неймспейс прямо на месте то сразу понятно что это и откуда. А если нет то приходиться лезть в начало файла и просматривать юзинги и гадать — к какому из них относиться искомый класс.
AVK>И еще один момент — чем больше юзингов тем выше вероятность конфликтов имен, которые в свою очередь могут привести к трудновылавливаемым глюкам. Ну и компиляция замедляется.

см (*).

AVK>

AVK>>>Без нужды конечно не стоит. Но писать юзинг ради единственного места где встречается этот неймспейс тоже не стоит.
Рек>>Вот тут не согласен. Стоит.
Рек>>Ты что же, если тебе нужна только одна функция CreateWindow,
Рек>>не подключаешь windows.h ? А выкусываешь один прототип и вставляешь
Рек>>его к себе в сишник? Использовать длинное считай тоже самое.
AVK>Ты издеваешься? Я тебе ввесь топик доказываю что хидеры и юзинг это принципиально разные вещи — а ты опять туда же? Вот тебе ответ на вопрос чем вредно — мыслишь в старых терминах и делаешь ошибочные выводы.
AVK>А пример немножко некорректен — если нужна CreateWindow то скорее всего из windows.h будет нужно много чего еще. Если же я уверен что кроме CreateWindow я точно не буду ничего использовать то таки да — опишу в своем хидере чем подключать монстра вроде windows.h.
Рек>>Хотя в этом случае можно использовать using с заданием синонима!
AVK>Да, это особо способствует читаемости кода, еще и алиасы в голове держать.

Думаю очень даже способствует.
При использовании синонимов получаются имена, которые и не полные, и не короткие,
а средние. Это будет бросаться в глаза (длиные имена запрещены!)
что поможет программисту повнимательнее отнестись к этим местам в программе.

На счёт держать в голове. Да надо.
Основные понятия предметной области надо загружать в оперативную память. :)
И это не сложно, т.к см (*)
Юзинг как бы задаёт контекст — вот здесь я буду рассуждать в этих терминах,
а там в других (и одни и теже слова будут означать разное в разных контекстах).
Отбрось физичесикй уровень, перейди на логический, и ты со мной согласишься!


Рек>>И опять всё будет хорошо.

AVK>Хорошо будет только при правильном понимании механизмов работы.

Механизмы — они на службе для обеспечения логики (структуры) программы.
(Если не понятно зачем, то зачем задавать воспрос как?)
Re[6]: Да, аналогично
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.10.02 09:58
Оценка:
Здравствуйте Рек, Вы писали:

Рек>Конечно ты прав.

Рек>Но моё предложение сводится к тому, что бы придать неймспейсам доп. смысл.

Не надо придавать ему никаких смыслов которым он не соответствует.

Рек>Считать неймспейс модулем,

Рек>а using считать объявлением об использовании этого модуля.
Рек>(неймспейсы организованы иерархически, и модули тоже, это нормально).

Ну не модуль это, практически ничего с модулем общего.

Рек>Чтобы такой взгляд был не противоречив, надо придерживаться доп ограничений при программировании — не использовать полные имена типов, а исползовать короткие или синонимы неймспейсов.


Зачем? Чтобы тебе не перестраивать свое мышление?

Рек>Да! Неймспейс физически не существует.

Рек>Но я предлагаю способ работы на логическом уровне.

Твое предложение ведет к неправильным выводам.

Рек>.Net не позволяет объявить об использовании класса.


При компиляции эта информация строиться автоматически.

Рек>Только об неймспейсе.


Опять 25 — юзинг не объявляет об использовании неймспейса, это хинт компилеру проверить присутствие онного в доступных сборках и потом искать классы в этих сборках.

Ты можешь написать using System.Text к примеру, но не использовать ни одного класса — при этом ссылки на сборку не будет.

Рек>Разве это не аргумент в пользу того, что неймспейсы это и есть модули?!


Уж если тебе так хочеться модулей то можешь в их качестве воспринимать сборки, как некую помесь модулей, хидеров и dll.

Да, кстати — в дотнете и модули есть, только студия их не поддерживает.

Рек>Я имел в виду, что 90% пространств имён умещается в одной сборке.


С чего бы это? Ты знаешь сколько в фреймворке родных сборок? И что например System.ComponentModel раскидан по нескольким сборкам и внутри сосуществует с другими неймспейсами?

Рек>Ты про #pragma ... lib ? Совсем нет.


Нет, я про #pragma no warning (с синтаксисом могу наврать, на С++ года 4 уже ничего не писал, но короче возможность отключать варнинги, некоторые ошибки и т.п.)

Рек>Думаю надо постараться сделать using более похожим на паскалевский use.


Это потому что тебе не хочеться переучиваться? Вот такое в паскале вполне допустимо
unit QQQ;
interface
 ...
end;

implementation
 ...
end;

begin
 Здесь некий код который будет выполняться если хоть где то в программе было uses QQQ
end.


Так вот — для неймспейсов такое в принципе невозможно. И это уже не детали реализации — это коренное различие именно в логике.


AVK>>Это уже от лукавого. Все равно если список юзингов вырастает больше 10-20 наименований никто в голове их уже не удержит. Так что с точки зрения читаемости для редко используемых неймспейсов лучше как раз юзинги не писать.


Рек>(*)

Рек>На это отвечу так. Если зашкаливют юзинги, то это значит,
Рек>что неправильно побит код на классы.

Да что ты. А то что на дизайн классов количество юзингов должно влиять в последнюю очередь это как бы фигня? Я из-за единственного использования чего нибудь вроде System.Threading.Thread.Sleep() должен лишний класс с двумя строчками кода писать?

Рек>Т.е всё свалено в кучу (всё использует всё).


А ты подумай. Например о том что использование например System.Windows.Forms на 95% потребует System.Drawing. Или о том сколько юзингов будет в файле с классами ядра системы. Я уж не говорю о том что туда может дизайнер студии напихать. Вот тебе юзинги из файла с весьма специфичным объектом
using System;
using System.IO;
using System.Xml;
using System.Data;
using System.Drawing;
using System.Reflection;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using Crownwood.Magic.Menus;
using Crownwood.Magic.Common;
using Crownwood.Magic.Controls;
using Crownwood.Magic.Collections;


А вот минимальный набор юзингов если класс работает с БД
using System;
using System.Data;
using System.Data.Провайдер;
using System.Xml;


Рек>При правильной структуре классов юзинги будут в файле тольно те, что

Рек>относятся к теме класса, их не бывает много (тк тем у класса не много),

Бывает.

Рек>а потому понятие "редкоиспользуемый" будет не актуальным.


А ты попробуй

Рек>Думаю очень даже способствует.

Рек>При использовании синонимов получаются имена, которые и не полные, и не короткие,

Вот только имена стандарных неймспейсов я почти все помню, а выдуманных тобой алиасов — ни одного.

Рек>а средние. Это будет бросаться в глаза (длиные имена запрещены!)

Рек>что поможет программисту повнимательнее отнестись к этим местам в программе.

Тебе может и поможет, а вот кому другому вряд ли.

Рек>На счёт держать в голове. Да надо.

Рек>Основные понятия предметной области надо загружать в оперативную память.

юзинги, а тем паче алиасы это не детали предметной области, это самая что ни на есть специфика компилера и платформы.
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
Re[7]: Да, аналогично
От: Рек Россия  
Дата: 24.10.02 14:59
Оценка:
Здравствуйте AndrewVK, Вы писали:

Рек>>Но моё предложение сводится к тому, что бы придать неймспейсам доп. смысл.

AVK>Не надо придавать ему никаких смыслов которым он не соответствует.

Добавить больше смысла в наши программмы никогда не лишне.
Если бы он соответствовал, то зачем бы тогда ещё что добавлять?

Рек>>Считать неймспейс модулем,

Рек>>а using считать объявлением об использовании этого модуля.
Рек>>(неймспейсы организованы иерархически, и модули тоже, это нормально).
AVK>Ну не модуль это, практически ничего с модулем общего.

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

Вот ещё один.
Ты склоняешься к тому, что модуль — это сборка.
Ан нет. То, что нэймспейс разбит на неск сборок ни как не отражается
в тексте программы. Какой же это модуль?!

Рек>>Чтобы такой взгляд был не противоречив, надо придерживаться доп ограничений при программировании — не использовать полные имена типов, а исползовать короткие или синонимы неймспейсов.

AVK>Зачем? Чтобы тебе не перестраивать свое мышление?

Просто так удобнее.

Рек>>Да! Неймспейс физически не существует.

Рек>>Но я предлагаю способ работы на логическом уровне.
AVK>Твое предложение ведет к неправильным выводам.
Например?

Рек>>.Net не позволяет объявить об использовании класса.

AVK>При компиляции эта информация строиться автоматически.
Рек>>Только об неймспейсе.
AVK>Опять 25 — юзинг не объявляет об использовании неймспейса, это хинт компилеру проверить присутствие онного в доступных сборках и потом искать классы в этих сборках.


Я использую слово "объявляет" не в строгом смысле (объявления в С++),
а в обыденном (житействком). Готов заменить его на слово "подсказывает" (программисту),
"информирует" (программиста).


AVK>Ты можешь написать using System.Text к примеру, но не использовать ни одного класса — при этом ссылки на сборку не будет.


Конечно не будет, но старательный коллега, может обмануться и
добавить reference на ненужную сборку.
Потому не надо так делать — это не безвредно, это обманывает.


Рек>>Разве это не аргумент в пользу того, что неймспейсы это и есть модули?!

AVK>Уж если тебе так хочеться модулей то можешь в их качестве воспринимать сборки, как некую помесь модулей, хидеров и dll.
AVK>Да, кстати — в дотнете и модули есть, только студия их не поддерживает.

Ой, давай про это не будем, а то запутаемся в терминологии в конец.

Рек>>Я имел в виду, что 90% пространств имён умещается в одной сборке.

AVK>С чего бы это? Ты знаешь сколько в фреймворке родных сборок? И что например System.ComponentModel раскидан по нескольким сборкам и внутри сосуществует с другими неймспейсами?

Возможно. Не настаиваю.

Рек>>Ты про #pragma ... lib ? Совсем нет.

AVK>Нет, я про #pragma no warning (с синтаксисом могу наврать, на С++ года 4 уже ничего не писал, но короче возможность отключать варнинги, некоторые ошибки и т.п.)
Рек>>Думаю надо постараться сделать using более похожим на паскалевский use.
AVK>Это потому что тебе не хочеться переучиваться? Вот такое в паскале вполне допустимо
Как раз наоборот — хочется научиться.
AVK>
AVK>unit QQQ;
AVK>interface
AVK> ...
AVK>end;

AVK>implementation
AVK> ...
AVK>end;

AVK>begin
AVK> Здесь некий код который будет выполняться если хоть где то в программе было uses QQQ
AVK>end.
AVK>


AVK>Так вот — для неймспейсов такое в принципе невозможно. И это уже не детали реализации — это коренное различие именно в логике.


А вот и нет!
Ровно для этого я предлагаю не использовать длинные имена. Тогда включение соотв. usinga
будет обязательным и следить за этим будет компилятор.

AVK>>>Это уже от лукавого. Все равно если список юзингов вырастает больше 10-20 наименований никто в голове их уже не удержит. Так что с точки зрения читаемости для редко используемых неймспейсов лучше как раз юзинги не писать.

Рек>>(*)
Рек>>На это отвечу так. Если зашкаливют юзинги, то это значит,
Рек>>что неправильно побит код на классы.

AVK>Да что ты. А то что на дизайн классов количество юзингов должно влиять в последнюю очередь это как бы фигня? Я из-за единственного использования чего нибудь вроде System.Threading.Thread.Sleep() должен лишний класс с двумя строчками кода писать?


Если using не наполнять смыслом (как ты предлагаешь), то должно влиять в последнюю очередь — это точно.
Но если в usingе есть смысл, то игнорировать его уже нельзя.

Рек>>Т.е всё свалено в кучу (всё использует всё).

AVK>А ты подумай. Например о том что использование например System.Windows.Forms на 95% потребует System.Drawing. Или о том сколько юзингов будет в файле с классами ядра системы. Я уж не говорю о том что туда может дизайнер студии напихать. Вот тебе юзинги из файла с весьма специфичным объектом
AVK>
AVK>using System;
AVK>using System.IO;
AVK>using System.Xml;
AVK>using System.Data;
AVK>using System.Drawing;
AVK>using System.Reflection;
AVK>using System.Collections;
AVK>using System.ComponentModel;
AVK>using System.Windows.Forms;
AVK>using Crownwood.Magic.Menus;
AVK>using Crownwood.Magic.Common;
AVK>using Crownwood.Magic.Controls;
AVK>using Crownwood.Magic.Collections;
AVK>


AVK>А вот минимальный набор юзингов если класс работает с БД

AVK>
AVK>using System;
AVK>using System.Data;
AVK>using System.Data.Провайдер;
AVK>using System.Xml;
AVK>


Ну. Всё нормально (на мой вкус). Разумное колво using'ов.

Рек>>При правильной структуре классов юзинги будут в файле тольно те, что

Рек>>относятся к теме класса, их не бывает много (тк тем у класса не много),
AVK>Бывает.

Просто надо приглядеться по внимательнее и увидеть,
что это не один класс, а целый набор. Одному много не по силам.

Рек>>а потому понятие "редкоиспользуемый" будет не актуальным.

AVK>А ты попробуй
Рек>>Думаю очень даже способствует.
Рек>>При использовании синонимов получаются имена, которые и не полные, и не короткие,
AVK>Вот только имена стандарных неймспейсов я почти все помню, а выдуманных тобой алиасов — ни одного.

Стандартные неймспейсов это особый разговор. Кстати не знаешь, есть ли способ
объединять нэймспейсы как в C++ ?

Рек>>а средние. Это будет бросаться в глаза (длиные имена запрещены!)

Рек>>что поможет программисту повнимательнее отнестись к этим местам в программе.
AVK>Тебе может и поможет, а вот кому другому вряд ли.

Почему? Необысное привлекает внимаете автоматически, на уровне подсознания.

Рек>>На счёт держать в голове. Да надо.

Рек>>Основные понятия предметной области надо загружать в оперативную память.

AVK>юзинги, а тем паче алиасы это не детали предметной области, это самая

что ни на есть специфика компилера и платформы.

Не согласен ни разу.
Если только ты не программируешь компилер или платформу.
В остальных случаях люди стремятся максимально точно отразить
предметную область в структуре и именах модулей (читай нэймспейсов).
Re: использование using
От: LOK Украина  
Дата: 24.10.02 15:01
Оценка:
А че нильзя написать прогу типа так.?


#import "Все что мне надо будет!" no_memory

"Покажи мне окно с гридом в котором выборка из 30 таблиц так как я захочу";

выход;


во круто да ?? никаких те куча юсингов
Re[8]: Да, аналогично
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.10.02 17:56
Оценка:
Здравствуйте Рек, Вы писали:

Рек>Добавить больше смысла в наши программмы никогда не лишне.

Рек>Если бы он соответствовал, то зачем бы тогда ещё что добавлять?

Смысл добавлять смысл в стандартные вещи? Смысл надо в дизайн добавлять.

Рек>Я перечислил неск потрясающе убедительных признаков по которым

Рек>можно утверждать, что к иерархии нэймспейсов можно относиться как
Рек>к иерархии модулей.

Тока ни один твой признак не соответствует действительности

Рек>Вот ещё один.

Рек>Ты склоняешься к тому, что модуль — это сборка.
Рек>Ан нет. То, что нэймспейс разбит на неск сборок ни как не отражается
Рек>в тексте программы. Какой же это модуль?!

Похоже мне твое мышление мне не поломать. Ну почему это должно отражаться? Неймспейс это не модуль и ничего общего с ним не имеет.
А то у тебя получается что что сборка не модуль потому что модуль это неймспейс.
Вот тебе очередной пример того к чему приводит неправильное понимание. Ты даже не задумываешься над этим.

Рек>Просто так удобнее.


Еще раз — тебе удобнее потому что ты не хочешь переучиться. Мне например удобнее воспринимать неймспейс тем чем он на самом деле является.

AVK>>Твое предложение ведет к неправильным выводам.

Рек>Например?

Я тебе в топике примеры приводил на твоих же словах. В этом еще один есть.

Рек>Конечно не будет, но старательный коллега, может обмануться и

Рек>добавить reference на ненужную сборку.
Рек>Потому не надо так делать — это не безвредно, это обманывает.
Конечно не надо. Просто это показывает что неймспейс совсем не похож на модуль. Один примерчик из януса — есть такой замечательный неймспейс — RSDN. Лежит он в нескольких сборках, но вот янусу нужна только одна. Мне что, для поддержания моих представлений стоит кучу немаленьких сборок и с клиентским и с серверным кодом собирать в одну?

Рек>Ой, давай про это не будем, а то запутаемся в терминологии в конец.


Во видишь, ты уже путаться начал, хотя там все прозрачно если не изобретать лишних сущностей.

AVK>>С чего бы это? Ты знаешь сколько в фреймворке родных сборок? И что например System.ComponentModel раскидан по нескольким сборкам и внутри сосуществует с другими неймспейсами?


Рек>Возможно. Не настаиваю.


Так что общего у неймспеса с модулем того же паскаля?

AVK>>Это потому что тебе не хочеться переучиваться? Вот такое в паскале вполне допустимо

Рек>Как раз наоборот — хочется научиться.

Ну так пострарайся вникнуть в суть неймспейса а не изобретай раковин.

AVK>>Так вот — для неймспейсов такое в принципе невозможно. И это уже не детали реализации — это коренное различие именно в логике.


Рек>А вот и нет!

Рек>Ровно для этого я предлагаю не использовать длинные имена. Тогда включение соотв. usinga
Рек>будет обязательным и следить за этим будет компилятор.

Зато привнесет кучу дополнительных проблем.

Рек>Если using не наполнять смыслом (как ты предлагаешь), то должно влиять в последнюю очередь — это точно.


Зачем не наполнять. Есть у него очень простой смысл — это пространство имен, не больше и не меньше. Ну как прям dns-имя. Оно может представлять несколько серверов, а может один сервер несколько имен.

Рек>Ну. Всё нормально (на мой вкус). Разумное колво using'ов.


Разумное, потому что на всякую мелочь не пишеться юзинг. А вот если писать — представляешь до чего разрастеться?

Рек>Просто надо приглядеться по внимательнее и увидеть,

Рек>что это не один класс, а целый набор. Одному много не по силам.

Пойми — логика разбиения на классы может быть совершенно иная, не связанная с используемыми неймспейсами. Т.е. классы могут быть небольшие и жестко ограниченные, но при этом использовать разные неймспейсы. Разбиение по неймспейсам, которое уже проведено не тобой, не единственное. Например было бы логично если класс использовал несколько разных сериалайзеров, а в дотнете все сериалайзеры раскиданы по нескольким разным неймспейсам.

Рек>Стандартные неймспейсов это особый разговор. Кстати не знаешь, есть ли способ

Рек>объединять нэймспейсы как в C++ ?

Не понял — как это?

AVK>>юзинги, а тем паче алиасы это не детали предметной области, это самая

Рек>что ни на есть специфика компилера и платформы.

Рек>Не согласен ни разу.

Рек>Если только ты не программируешь компилер или платформу.
Рек>В остальных случаях люди стремятся максимально точно отразить
Рек>предметную область в структуре и именах модулей (читай нэймспейсов).

Поизучай на досуге неймспейсы фреймворка — к примеру System. У его классов ну очень много общего . Microsoft.Win32 тоже хорошо отражает предметную область своих классов. System.Net единственный работающий с сетью, а System.Web как бы уже нет? Хотя по твоей логике его надо было обозвать что то вроде System.Net.Web. Еще вопрос — в котором из них находиться WebRequest, в System.Net или в System.Web? А HttpRequest? Ну и т.д
... << RSDN@Home 1.0 alpha 12 (developers build)>>
AVK Blog
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.