Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:

К>>Вот не надо, Сергей, только опять навязывать все вирт. языки как "единственно верные"...
К>>Скажи мне, где в Java, к примеру, есть модули?
К>>Или на каждый класс нужно в пр-во имён заворачивать? А потом указывать именно пр-во имён вместо класса?

СГ>Как одновременно: "1) Вот не надо, Сергей, только опять..." и "2) Скажи мне, где в Java..."? На второй пункт я бы мог ответить, но первый пункт запрещает это сделать.
Прочитай ещё раз и убедись, что они нисколечки друг другу не противоречат.
Просто пиши, что ты говоришь только о виртовских языках, а остальное чушь, иначе нельзя твои реплики воспринимать иногда — бред получается, имхо
СГ>Вот если бы он не запрещал, то я бы ответил, что пространства имен — тупиковая ветвь в развитии языков программирования появившаяся из-за отсутсвия модульности. Куда ни ткни везде с модульностью — ни каких проблем, а с пространствами имен сплошные грабли. Вот и тут опять же такие грабли они подложили. Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...

Почему нельзя? Объясни!
Не надо заявлять о недостатках чего-то, если ты не можешь этого доказать
В жабе нельзя (как и в C#), потому что они "pure OOP", т.е. там свободных ф-ций не может быть вообще по определению. В C++ спокойно может, так что ты опять что-то придумал и выдаёшь за правду, не хорошо это...


К>>

СГ>/* 1-й элемент */
СГ>g(X, a, b, c);
СГ>/* последний элемент */
СГ>g(a, b, c, X);
СГ>

К>>так понятней?

СГ>Так понятней. А какая разница-то? Можно и так: g(a, X, b, Y, c, Z); — для трех объектов X, Y, Z...

Вопрос в том используешь ли ты ООП или нет, если нет — то ради бога, но тогда и не заикайся про него, плиз.
А если в соотв. с ООП, то у тебя:
1. есть объект
2. есть операции, применяемые к этому объекту
Соотв-но ты должен понимать к какому из объектов относится операция.

Другое дело, что такой подход есть несколько "узкая" часть ООП, с той т.зр., что иногда операция не определяется лишь 1 объектом, но мультиметоды — это тема для отдельного обсуждения (имхо, в реальной жизни они встречаются далеко не так часто, хотя это зависит от т.зр. естественно)

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

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

СГ>> ... Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...

К> Почему нельзя? Объясни!

Ах все-таки можно, тогда о чем разговор? Можно ведь.


К> З.Ы. ты путаешь "модульность" виртовскую с ООП и поэтому у тебя получается одно на другое налезает, но это очень пересекающиеся идеи, поэтому вместе их рассматривать не очень корректно.

То-то и оно. Объединение "ООП + МОДУЛЬНОСТЬ" не может оставить само ООП в своем прежнем виде. Многие вещи в нем становятся излишними. Так например, те же самые невиртуальные методы — зачем они нужны если они заменяются простыми процедурами? Не нужны они и все тут. Метод от того и метод что он связан с типом, а значит может быть переопределен при расширении типа, другими словами он всегда виртуален. А если не собираешься его переопределять, то есть не собираешься делать его виртуальным, так и используй для этого простые процедуры того же модуля в котором определен тип. Честно признаться, этот топик был затеян мной как ответ на вопрос Vlad2: "Почему в Oberon-2 все методы виртуальные?". А затем, что не виртуальные и так есть — это простые процедуры того же самого модуля в котором определен тип. В расширении языка Oberon-2 в Component Pascal создатели все-таки добавили в язык и не виртуальные методы тоже, видимо пошли на поводу у современной ООП моды...

XopoSHiy -> "Re[5]: Связанные с типом процедуры должны быть виртуальными"

X>>> Методы в Perl-e реализованны именно с помощью такой конструкции!
hrg>>"Не позволю с Вами согласится"(с) хз чей

hrg>>$grid->UpdateContents();
hrg>>без всяких лишних телодвижений и лишних параметров.

X> Это синтаксические навороты языка. Фактически это эквивалентно
X> следующей записи:
X> GridsPackage::UpdateContents($grid);

Ну я как бы в теме

X> Ещё разик: В
X> перле методы реализованы именно как внешние функции. В
X> частности у
X> одного объекта можно вызывать совершенно не его методы.
X> Но всё это
X> обёрнуто в "удобную" синтаксическую конструкцию,
X> напоминающую вызов
X> метода в других языках.

X> Собственно там даже метод класса (статический в
X> терминах С++) не
X> отличается от обычных методов: если первым параметром
X> пришёл объект,
X> то метод обычный, если первым параметром пришёл пакет -
X> то это метод
X> класса.

Может и ничего не приходить первым параметром. Если вызов Package::method.
Ну это так, к слову

X> К слову, Перл позиционируется как язык не
X> скрывающий от программиста
X> ничего! Там крайне сложно (если вообще
X> возможно) создать private или
X> protected метод. Видимо, из-за такой

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

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


Все успешно реализуется и раграничивается при желании. Если оно есть

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:

СГ>>> ... Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...

К>> Почему нельзя? Объясни!

СГ>Ах все-таки можно, тогда о чем разговор? Можно ведь.
Вот и я говорю — всё нормально, а ты где-то грабли нашёл, а теперь сам говоришь: "так нет же их", ты ужасно последователен


К>> З.Ы. ты путаешь "модульность" виртовскую с ООП и поэтому у тебя получается одно на другое налезает, но это очень пересекающиеся идеи, поэтому вместе их рассматривать не очень корректно.

СГ>То-то и оно. Объединение "ООП + МОДУЛЬНОСТЬ" не может оставить само ООП в своем прежнем виде. Многие вещи в нем становятся излишними. Так например, те же самые невиртуальные методы — зачем они нужны если они заменяются простыми процедурами? Не нужны они и все тут. Метод от того и метод что он связан с типом, а значит может быть переопределен при расширении типа, другими словами он всегда виртуален. А если не собираешься его переопределять, то есть не собираешься делать его виртуальным, так и используй для этого простые процедуры того же модуля в котором определен тип. Честно признаться, этот топик был затеян мной как ответ на вопрос Vlad2: "Почему в Oberon-2 все методы виртуальные?". А затем, что не виртуальные и так есть — это простые процедуры того же самого модуля в котором определен тип. В расширении языка Oberon-2 в Component Pascal создатели все-таки добавили в язык и не виртуальные методы тоже, видимо пошли на поводу у современной ООП моды...

Имхо это не мода, а нормальное человеческое понимание предметной области, про модули ты так и не объяснил — на кой оно надо и что это такое? Вот с объектами гораздо понятней:
есть объект и он есть чёрный ящик, есть только "ручки, за которые его тыркать можно", т.е. его операции.
А вот модуль — есть очень искусственная конструкция, имхо, не чем не обоснованно введённая в язык, не более того...
И эта "искусственность" портит всю картину, вылезая из всех щелей...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mr. None, Вы писали:

MN>>...любой новый метод, будет реализовываться через уже имеющиейся методы, и это нарушит данный принцип. Именно такие "методы" Мейерс и предлагает делать внешними. Чувствуете разницу между этими словами и вашим предложением?

СГ>Да, чувствую. Слово интерфейс — широко в своем значении. У того что обозначается interface в Delphi, C#, Java — у него все методы "виртуальные". Не виртуальных методов в таком интерфейсе нет. Вот и Вы тоже почувствуйте разницу.

Слушайте, давайте говорить по существу или хотя бы внимательно читать сообщения. Я ни где ни разу не обмолвился о ключевом слове interface или виртуальной функции. Публичный интерфейс класса — это список его публичных методов, если вы не знали, а уж виртуальные они или нет — это дело уже десятое. Интерфейсом вообще называют всё, с помощью чего происходит общение двух субъектов или один субъект использует возможности другого. Я не поднимал дискуссии насчёт понятий интерфейсов в ООП и поднимать больше не хочу — мы с вами уже не раз диспутировали по этому вопросу и в своё время я сказал всё, что хотел, если не помните, воспользуйтесь поиском.
Если уж на то пошло то ваше обобщение вообще не корректно, потому что всё что предложено Мейрсом в части реализации его идей касается впервую очередь языка C++. Сама теория минимальности и полноты интерфесов, а также доказательство того, что дополнительные методы уменьшают инкапсуляцию расширима на многие языки, но приведённый им и процитированный вами алгоритм касается исключительно языка C++.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.
Кстати, не ты первый об этом задумался...
— У Александреску в "MC++D" (7.4 Smart Pointer Member Functions) есть следующий абзац:

For reasons of clarity, SmartPtr does not have any named member functions. The only functions that access the pointee object are GetImpl, GetImplRef, Reset, and Release, which are defined at the namespace level.

— В boost наблюдается похожая тенденция: функции-экстракторы из различных контейнеров (boost::any,boost::variant,boost:shared_ptr) реализованы как не-члены.

Александреску свое решение мотивирует тем, что smart pointer служит заменой обычному пойнтеру, а у обычного пойнтера функций-членов нету. Чем мотивируется решения в Бусте — не знаю, но подозреваю что они прислушались к Александреску.

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

DEA>- В boost наблюдается похожая тенденция: функции-экстракторы из различных контейнеров (boost::any,boost::variant,boost:shared_ptr) реализованы как не-члены.

DEA>Чем мотивируется решения в Бусте — не знаю, но подозреваю что они прислушались к Александреску.
Тем, что по-другому невозможно. У функции-члена нельзя явно прописывать инстанциацию (тьфу, о чем я? короче, в терминах запутался, вот пример: )

any.get<int>(); //так низзя
get<int>(any); //а так - мона.

Если только я ничего не путаю

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

XSH>Просто так рубить с плеча — нехорошо... Вот Мейерс более аккуратен, хотя я бы и с ним поспорил, была бы возможность

Мейерс, очевидно, смотрит на язык С++, а не на "языки вообще". Это существенно, поскольку именно в С++ широко распространена практика перегрузки, в том числе операторов.

Если, к примеру, мы реализуем операцию вывода в поток (оператор <<) без перегрузки — то мы должны
* или родить новое имя Print_XXX(var strm:TextStream, const data:XXX) — неважно, в глобальном пространстве имён или в подпространстве — XXX_tools.Print
* или добавить новый метод в уже готовый класс TextStream (что, как правило, невозможно)
* или добавить метод в класс XXX (что тоже не всегда возможно) и получить "страдательный залог" — data.BePrintedWith(strm)

Что же касается friend'ов и т.п.

Внешняя функция, разумеется, обращается к членам аргументов. Можно сократить это общение до вызова методов (особенно — полиморфных), и более того, можно превратить эту функцию в диспетчера, вызывающего нужный метод одного из аргументов — в действительном или страдательном залоге, как повезёт
Роль функции-диспетчера двояка:
1) придаёт вызову метода удобный вид (читаемый, осмысленный, согласованный с перегрузкой этого имени)
2) абстрагирует реализацию, задействуя runtime- или compiletime-полиморфизм если он есть, даёт больше возможностей для модификации программы.

Однако, если функция проектируется одновременно с классом, метод которого будет вызван из неё, то встаёт вопрос:
а кому ещё нужен этот метод?
Если больше никому (пресловутый страдательный залог), то есть смысл сделать его приватным, а функцию — другом.
Впрочем, это дело вкуса.

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

СГ>>А в других многих языках инкапсуляция осуществляется на уровне модуля. Все описанное внутри одного модуля "дружит" друг с другом.

XSH>Много бы я отдал, чтобы этого не было в Delphi. Все ноги переломаешь, пока разберёшься в таком "дружественном" коде...
XSH>Frien-ы — вообще ненужная вещь

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

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

К>А вот модуль — есть очень искусственная конструкция, имхо, не чем не обоснованно введённая в язык, не более того...

Единица исполнения — структурная динамически загружаемая единица системы, единица расширения системы, единица компиляции, единица инкапсуляции, единица хранения кода, и много чего еще единица — и все это искусственная конструкция? Как же так?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:

К>>А вот модуль — есть очень искусственная конструкция, имхо, не чем не обоснованно введённая в язык, не более того...

СГ>Единица исполнения — структурная динамически загружаемая единица системы, единица расширения системы, единица компиляции, единица инкапсуляции, единица хранения кода, и много чего еще единица — и все это искусственная конструкция? Как же так?

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

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

СГ>> Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.

DEA> Кстати, не ты первый об этом задумался...

Знаю что не я первый об этом задумался. Например, в языке Oberon-2 все методы виртуальные потому, что не виртуальные и так есть — это простые процедуры того же самого модуля в котором определен тип.

http://www.rsdn.ru/Forum/Message.aspx?mid=892123&amp;only=1

Автор: Сергей Губанов
Дата: 10.11.04

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

К>Вот так — искусственная, про то, что единица кода есть лишь только текстовый файл тебе писали не 1 раз, про остальное тоже. Никаких членораздельных аргументов я так и не услышал

Вот членораздельный аргумент:

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

Внес изменение в 1 текстовый файл, скомпилировал его в 1 маленький исполнимый файл, заменил старый исполнимый файл на этот новый во всех уже проданных по всему миру системах и спишь спокойно. А можно заменить его не на один, а, например, на три новых модуля.

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

Вдобавок, некоторые системы могут использовать разные модули от различных производителей, а в случае единственного гигантского исполнимого файла это невозможно.


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

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

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

СГ>>>А в других многих языках инкапсуляция осуществляется на уровне модуля. Все описанное внутри одного модуля "дружит" друг с другом.

XSH>>Много бы я отдал, чтобы этого не было в Delphi. Все ноги переломаешь, пока разберёшься в таком "дружественном" коде...
XSH>>Frien-ы — вообще ненужная вещь

К>А вот неправда. Дельфи навязывает дружбу. И получается не дружба, а коммуналка.
К>В С++ приходится заявлять — этот и этот мне друзья, со всей ответственностью. Просто не дружите с кем попало, и будет вам щастье.
Интересно, а почену в Net отказались от столь эффективных друзей в пользу ассембли и комбинации её с protected ????

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:

К>>Вот так — искусственная, про то, что единица кода есть лишь только текстовый файл тебе писали не 1 раз, про остальное тоже. Никаких членораздельных аргументов я так и не услышал

СГ>Вот членораздельный аргумент:

[поскипано, ибо больно дохрена]

Сергей, всё равно это есть искусственное деление, сколько ты не говори, модульность и ООП — вещи ортогональные должны быть, т.е. с т.зр. "невиртовских" языков есть процедуры, классы и проч. с 1 стороны, которые могут быть далеко не в 1 файле, а с др. стороны есь DLL, SO или любой другой "модуль", ну и соотв-но описывается программером, что же запихивать туда. И, соотв-но в этой схеме нет никаких особых противоречий с ООП — всё довольно стройно. И нет гигантских эгзешников ибо уже давным давно найдены механизмы (причём множество) создания модульных программ. И даже в C (без плюсов) можно этой модульности добиться, возможно с заморочками, но далеко не такими страшными...
Т.е. вынесение "модуля" на уровень языка я считаю плохой идеей ибо с т.зр. предметной области это совсем уж искусственное понятие и имеет лишь отношение к распространению бинарников, не более того...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вопрос: а зачем так сложно? Давайте проще:

СГ>Все связанные с типом процедуры — виртуальны, а если нужны не виртуальные, а обычные, то для этого есть обычные процедуры не связываемые с типом.

СГ>Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.

Больная идея.
Например возьмем такой полезный класс string, который юзается повсеместно и должен быть удобным.
В нем есть методы:

// метод 1
// присваивает строку str длинной size
// допустим он виртуальный
void string::assign( const char *str, uint size ); 

// метод 2
// это для удобства вызывает метод 1
void string::assign( const char *str )
{
   assign( str, strlen(str) );
}

// метод 3
// тоже для удобства
void string::assign( const char *begin, const char *end )
{
   assign( begin,end-begin );
}

Вот и спрашивается зачем метод 2 и 3 должны быть виртуальными? Более того такие методы делают инлайнами и они фактически раскрываются в метод 1. Получается что следуя логике (все виртуальное) я должен писать либо всегда:

void test( const char *s1, const char *s2_beg, const char *s2_end )
{
  string s;
  s.assign( "zzzzz", strlen("zzzzz") ); // бррр
  s.assign( s1, strlen(s1) );
  s.assign( s2_beg, s2_end - s2_beg );
}

либо:

void test( const char *s1, const char *s2_beg, const char *s2_end )
{
  string s;
  string_assign(s,"zzzzzz"); // перегруженные процедуры хелперы
  string_assign(s,s1);
  string_assign(s,s2_beg,s2_end);
}

и зачем этот гемор когда можно написать просто:
void test( const char *s1, const char *s2_beg, const char *s2_end )
{
  string s;
  s.assign( "zzzzz" );
  s.assign( s1 );
  s.assign( s2_beg, s2_end );
}

Вот и я об этом певцу оберона говорю...
Пример со строкой, кстати — очень хороший.

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

К>Скажи мне, где в Java, к примеру, есть модули?

Прошу прощения, по-моему, package'ы в Java выполняют именно функцию модулей.
Разве нет?

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

K>Например возьмем такой полезный класс string, который юзается повсеместно и должен быть удобным.

1) Зачем строке иметь виртуальный метод? Тип строки описывается один раз и навсегда, зачем его потом расширять?

2) А строки, вообще-то, нехорошо в качестве примера приводить, так как работа со строками обычно встроена в сам язык программирования... Давайте лучше вместо строк рассмотрим тип целых чисел произвольного размера. У них тоже нет ни одного виртуального метода — зачем он им?

DEFINITION Integers;

    IMPORT Files;

    TYPE
        Integer = POINTER TO IntegerDesc;

    PROCEDURE Abs (x: Integer): Integer;
    PROCEDURE Compare (x, y: Integer): INTEGER;
    PROCEDURE ConvertFromString (IN s: ARRAY OF CHAR; OUT x: Integer);
    PROCEDURE ConvertToString (x: Integer; OUT s: ARRAY OF CHAR);
    PROCEDURE Difference (x, y: Integer): Integer;
    PROCEDURE Digits10Of (x: Integer): INTEGER;
    PROCEDURE Entier (x: REAL): Integer;
    PROCEDURE Externalize (w: Files.Writer; x: Integer);
    PROCEDURE Float (x: Integer): REAL;
    PROCEDURE GCD (x, y: Integer): Integer;
    PROCEDURE Internalize (r: Files.Reader; OUT x: Integer);
    PROCEDURE Long (x: LONGINT): Integer;
    PROCEDURE Power (x: Integer; exp: INTEGER): Integer;
    PROCEDURE Product (x, y: Integer): Integer;
    PROCEDURE QuoRem (x, y: Integer; OUT quo, rem: Integer);
    PROCEDURE Quotient (x, y: Integer): Integer;
    PROCEDURE Remainder (x, y: Integer): Integer;
    PROCEDURE Short (x: Integer): LONGINT;
    PROCEDURE Sign (x: Integer): INTEGER;
    PROCEDURE Sum (x, y: Integer): Integer;
    PROCEDURE ThisDigit10 (x: Integer; exp10: INTEGER): CHAR;

END Integers.

IMPORT StdLog, Integers;

VAR n: Integers.Integer; s: POINTER TO ARRAY OF CHAR;
BEGIN
  n := Integers.Power( Integers.Long(123456789),  2323232);  (* n = 123456789 ^ 2323232 *)
  NEW(s, Integers.Digits10Of(n) + 1);
  Integers.ConvertToString(n, s);
  StdLog.String("123456789 в степени 2323232 = "); StdLog.String(s);

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Kluev, Вы писали:

K>>Например возьмем такой полезный класс string, который юзается повсеместно и должен быть удобным.

СГ>1) Зачем строке иметь виртуальный метод? Тип строки описывается один раз и навсегда, зачем его потом расширять?

СГ>2) А строки, вообще-то, нехорошо в качестве примера приводить, так как работа со строками обычно встроена в сам язык программирования... Давайте лучше вместо строк рассмотрим тип целых чисел произвольного размера. У них тоже нет ни одного виртуального метода — зачем он им?

[поскипано]

Сергей ты намеренно приводишь не корректные примеры? Ты знаешь разницу между "примитивными" типами (они же value-типы) и классами "обычными?
Если да (на что я очень надеюсь), то посмотри в исходное сообщение своё — что там объектом было? Класс или целые числи или что-либо подобное?