Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Так инкапсуляция либо есть либо нет. А атрибутов много.
ANS>Значит в чем то другом дело.
Наива. Инкапсуляция — это возможность публиковать различные контракты для различных потребителей. Количество модификаторов доступа напрямую определяется количеством типов отношений кода с потребителями. Для процедурных языков такой классификации не существует. Для модульных языков процедура-потребитель может находиться либо в том же модуле, либо в другом. Для объектно-ориентированных языков объект-потребитель принадлежит либо тому же классу, либо его потомку, либо любому другому. И т.д. Наиболее развитые сейчас (афаик) в плане структурирования кода платформы — .Net и Java. Подсчет количества модификаторов доступа в них оставляю в качестве домашнего задания.

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

S> Подсчет количества модификаторов доступа в них оставляю в качестве домашнего задания.

Много.

И напомнило мне это славный анекдот:

Стоият два милиционера в Киеве на Крещатике.
Подходит к ним иностранец и на хорошем
украинском языке спрашивает "Громадянэ, как пройти на Хрещатик?".
Молчат милиционеры. По немецки спросил. По русски. По испански — все равно
тишина.
Пять минут проходит, один служ. пор. говорит другому:

"Миколо, ты ба! Скильки язикив чоловик знаэ..."

"Тю! Та хиба ж це йому допомогло?"

(Три смысловых слоя)

c-smile wrote:

> S> Подсчет количества модификаторов доступа в них оставляю в качестве
> домашнего задания.
> Много.

Немного. А если точнее, то в Java их всего 4: public, default, protected
и private.

Если считать static модификатором доступа, то будет 8.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Спасибо !!! Всё заработало!

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

L>>не работает ?!?!??!
D>Хм? Странно... Посмотрю дома — отвечу завтра

L>>Вот что я делаю.

L>>Есть два файла lib.d и lib_r.d
L>>/*********************************** lib.d **************************************/
L>>class A
L>>{
L>>export
L>>{
L>> this();
L>> ~this();
L>> int get();
L>>}
L>>/********************************************************************************/
L>>/*********************************** lib_r.d **************************************/
L>>import std.stdio;
L>>class A
L>>{
L>>export
L>>{
L>> this() { printf("constructor\n"); }
L>> ~this() { printf("destructor\n"); }
L>> int get() { return 0; };
L>>}
L>>/********************************************************************************/

L>>далее собираю библиотеку
L>>dmd -c -O -release lid_r.d
L>>lib -c mylib.lib lib_r.obj
L>>получаем mylib.lib

L>>далее есть main.d
L>>/*********************************** main.d **************************************/
L>>import std.stdio;
L>>import lib;

L>>int main()
L>>{
L>> A a = new A();
L>> return 0;
L>>}
L>>/********************************************************************************/
L>>собираю
L>>dmd -O -release -L mylib.lib main.d
D>А зачем здесь опция -L?

L>>он начинает ругатся что типа незнает A;
L>>но если я заменю import lib на import lib_r
L>>все собирается и работает?
D>Так-то понятно — она к библиотеке не обращается...

L>>Что делать?
D>Может, я ошибся в совете... Попробуй сделать так:
D>

D>module mypackage.lib_r
D>import std.stdio;

D>export
D>{
D>  class A 
D>  {
D>    this() { printf("constructor\n"); }
D>    ~this() { printf("destructor\n"); }
D>    int get() { return 0; };
D>  }
D>}


D>module mypackage.lib

D>export
D>{
D>  class A 
D>  {
D>    this();
D>    ~this();
D>    int get();
D>  }
D>}

D>module mypackage.main
D>import std.stdio;
D>import lib;

D>int main()
D>{
D>  A a = new A();
D>  return a.get();
D>}
D>

Привет, D собратья.

Будем дольше развивать темы про D.
Теперь у меня такой вопрос?

Кто ни будь, тестировал D на производительность??
Что можете сказать?
Как он себя показывает на фоне компиляторов от Microsoft и от g++?
Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях??
Как можно оптимизировать?

Были ли серьёзные проекты на D? Каков их успех?

Здравствуйте, Cyberax, Вы писали:
C>Немного. А если точнее, то в Java их всего 4: public, default, protected
C>и private.
Верно. На 1 больше, чем в с++. И ровно потому, что появилась новая единица структурирования — пакет.
C>Если считать static модификатором доступа, то будет 8.
Ну, статик на visiblity не влияет. Так что вместе с final выкидываем его из рассмотрения.

L>Кто ни будь, тестировал D на производительность??
L>Что можете сказать?
L>Как он себя показывает на фоне компиляторов от Microsoft и от g++?
L>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях??
L>Как можно оптимизировать?
Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml

Автор(ы): Петр Каньковски
Дата: 11.04.2004
Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.

L>Были ли серьёзные проекты на D? Каков их успех?
Спроси c-smile Он на нем пишет достаточно серьезную систему (в этом форуме все пробегало...)

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

L>>Кто ни будь, тестировал D на производительность??
L>>Что можете сказать?
L>>Как он себя показывает на фоне компиляторов от Microsoft и от g++?
L>>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях??
L>>Как можно оптимизировать?
D>Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml

Автор(ы): Петр Каньковски
Дата: 11.04.2004
Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.

В этой статье только слова, а мне бы цифры? И сравнения!

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

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

L>>>Кто ни будь, тестировал D на производительность??
L>>>Что можете сказать?
L>>>Как он себя показывает на фоне компиляторов от Microsoft и от g++?
L>>>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях??
L>>>Как можно оптимизировать?
D>>Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml

Автор(ы): Петр Каньковски
Дата: 11.04.2004
Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.

L>В этой статье только слова, а мне бы цифры? И сравнения!
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25252
D чего-то там выиграл по цифирькам...

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

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

L>>>Кто ни будь, тестировал D на производительность??
L>>>Что можете сказать?
L>>>Как он себя показывает на фоне компиляторов от Microsoft и от g++?
L>>>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях??
L>>>Как можно оптимизировать?
D>>Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml

Автор(ы): Петр Каньковски
Дата: 11.04.2004
Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.

L>В этой статье только слова, а мне бы цифры? И сравнения!

"...и опыт сын ошибок..."

Самое надежное: написать для себя пример
имплементирующий простую mission critical функцию
на двух трех языках. По результатам — осознанно выбрать.
Рекламным материалам верить можно до определенного
предела. Если вообще можно.

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

C>Если считать static модификатором доступа, то будет 8.

static не является модификатором доступа.

WH>Здравствуйте, Andrei N.Sobchuck, Вы писали:

WH>>>В контроле инкапсуляции компилятором.
ANS>>Так инкапсуляция либо есть либо нет. А атрибутов много.
ANS>>Значит в чем то другом дело.
WH>Дело в уровнях инкапсуляции.

Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?

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

Желания запретить пользоваться своим кодом кому бы то ни было я решительно не понимаю. Вопросов бы не было, если бы эти модификаторы помогали поддерживать стабильными публичные интерфейсы. Так глядя на кучу "depreciated" в Java и .Net видно, что к этой задаче модификаторы не пригодны.

WH>public — Публичный интерфейс класса.
WH>protected — Интерфейс класса доступный потомкам.
WH>internal — Интерфейс класса доступный внутри сборки.
WH>private — Детали реализации класса.

Кстати, хорошим аргументом "против" является экстенсивное наращивание модификаторов. От С++ через Java к .Net. А завтра кому-то захочется "защитится" от классов в одном пространстве имён. Бац, новый модификатор. А потом для разных комбинаций пространств имён и пакетов... (А в каждой шутке, как известно, только доля шутки.)

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
Например есть класс дерево и класс ветка дерева. Для взаимодействия между ними нужен болие широкай интерфейс чем для взаимодействия с внешним миром.

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

ANS>>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
WH>Например есть класс дерево и класс ветка дерева. Для взаимодействия между ними нужен болие широкай интерфейс чем для взаимодействия с внешним миром.

И что? Ты же не утверждаеш, что не используя модификаторов доступа не возможно создать классы дерева и ветки?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>И что? Ты же не утверждаеш, что не используя модификаторов доступа не возможно создать классы дерева и ветки?
А то что иначе эти классы будут иметь слишком большой интерфейс который не нужен их пользователям.

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

ANS>>И что? Ты же не утверждаеш, что не используя модификаторов доступа не возможно создать классы дерева и ветки?
WH>А то что иначе эти классы будут иметь слишком большой интерфейс который не нужен их пользователям.

Ты уверен на все 100, что этот интерфейс мне не нужен?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая?
Я рекомендую тебе воспользоваться поиском. Вопрос о модификаторах доступа здесь уже досконально обсасывался. Специально для тебя повторю главную тему: инкапсуляция = возможность предоставлять контролируемый контракт потребителям. Для потребителей в различных, скажем так, зонах, можно предоставлять различные контракты.
То, что это необходимо — очевидно.
ANS>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.

Если мы сделаем конструктор приватным, то
а) невозможно будет сделать фабрику отдельным классом. Потому, что ему тоже будет нельзя вызывать конструктор
б) невозможно будет отнаследоваться от такого класса, т.к. потомок не сконструируется.
Если мы сделаем конструктор публичным, то никакого контроля над созданием объекта не получится.
Если мы распространим приватную область видимости на пределы модуля, то в него автоматически приедут все классы, связанные с одним из них.

Простейшая штука номер два: параноидальный подход при конструировании класса требует проверять все приходяшие в методы значения на валидность. И кидать исключение, если что.
При этом каждый вызов получает дополнительные накладные расходы.
Уровень доступа "сборка" позволяет нам предоставить менее безопасный, но более производительный интерфейс ограниченному кругу потребителей. Причем, по удачному совпадению, это ровно тот круг потребителей, которые находятся под нашим контролем. Поэтому мы можем гарантировать валидность передаваемых параметров административными методами и статическим анализом кода.

З.Ы.
Тебя не удивляет, что в жизни все далеко не делится только на личное и общее? Ты даешь свой телефон друзьям, а ключ от квартиры любимой девушке. При этом посторонние не получат ни того, ни другого, хотя могут спокойно спросить у тебя "сколько времени". В программировании — то же самое.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

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

WH>public — Публичный интерфейс класса.
WH>protected — Интерфейс класса доступный потомкам.
WH>internal — Интерфейс класса доступный внутри сборки.
WH>private — Детали реализации класса.

+ protected internal — Интерфейс класса доступный потомкам и внутри сборки.

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

WH>Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным?

Автор, не богохульствуй!

Пишу на досуге на PHP довольно тяжёлую программу. Очень интересный язык оказался. Но вот отсутствие явной спецификации типов и отсутствие приватных элементов (они появились в пятой версии) задалбывает.