Ответ на »сообщение 3923« (Trurl)
___________________________


Ну, уж если проводить аналогию. В первом случае мы берем модуль со столовыми приборами и применяем их к торту. Во втором мы говорим торту "Разрежься!" и он сам разрезается. Наверное, второй вариант выглядит более соблазнительно, но как-то дальше от реальности. По крайней мере, я пока не встречал в продаже саморазрезающихся тортов.


На самом деле относительно этой аналогии можно спорить до бесконечности. Но, всё же отвечу. В случае с модулями мы купили торт в магазине (= объявили в модуле-клиенте переменную типа Торт, экспортируемого модулем-сервером Магазин), затем, чтобы разрезать торт, несём его в место, где это умеют делать (= передаём переменную типа Торт как параметр в операцию Разрезать модуля ОперацииСТортом (эта операция не обязательно должна быть объявлена в модуле Магазин, хотя такое решение и противоречит в некоторой степени понятию АТД, но в свете упоминавшегося высказывания Вирта о контрасте между АТД и Расширяемым Типом Данных, вполне допустимо)).
В случае с классами всё очень неоднозначно. Торт поставляется нам с уже определённым набором операций, которые мы можем над ним осуществлять. Чтобы разрезать торт, нам нужно послать ему сообщение Торт.Разрезать (Вы использовали для этого волшебное слово "Разрежься!", я же сказал, что мы взяли нож и начали резать), а непосредственно процесс разрезания определяется свойствами самого торта (его, так сказать, природой), а не тем, кто будет его резать (ведь и в реальной жизни так: возьмите 1000 человек и предложите им разрезать торт -- ручаюсь, они сделают это примерно одинаково (размер куска определяется инициатором действия, т.е. тем, кто посылал сообщение и от свойств торта практически не зависит)).

Ответ на »сообщение 3935« (Руслан Богатырев)

Подскажите, как можно это сделать, не зная, что понимается вами под словом "оптимизированный" и под сочетанием "модульные системы"?

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

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

Как сказал бы в данном случае ASU, свободно жонглировать словами "модуль" и "компонент" мне удаётся потому, что я чётко понимаю их смысл. Вы же, пока, этот смысл только ищете.

Назовите хотя бы парочку систем, которые сделаны не на языках Оберон-семейства, но которым вы никак не откажете в праве называться модульными.

Windows & Linux

*.DLL - модуль ОС Windows
*.SO - модуль ОС Linux

Ответ на »сообщение 3921« (Руслан Богатырев)
___________________________


Если мы хотим использовать модуль, то мы не должны объявить переменную экспортируемого модулем типа. Мы можем это сделать и то, если нам нужен экспортируемый тип, а не что-то другое. Но если сводить к работе с модулем исключительно как с АТД, то конечно, переменную нужно объявлять. Не думаю, однако, что это сильно вас смущает.

Не нужно цепляться к словам. Разумеется под использованием модуля я имел в виду использование объявленного там типа данных.


Видимо вас смущает то, что в случае модулей (как вы считаете) обращение к методам (операциям) строится иначе в человеческом восприятии. Т.е. вместо "модуль.операция(параметры)" применяется "класс.метод(параметры)". В языках малого Оберон-семейства вторая форма так и выглядит. Более того, в языках Оберон-2 и Компонентный Паскаль использутся т.н. связанные процедуры (type-bound). Они "намертво" привязаны к типу. И в этом смысле являются методами-константами для всех экземпляров данного класса.


Меня смущает независимое существование данных и операций (мой пример с тортом). Хотя, согласен, аргумент далеко не самый сильный.


В языке Оберон (но не в Оберон-2 и не в КП) можно создавать класс, в котором у любого его экземпляра (забудем на время про производные классы) можно полностью заменить все методы. Заменить на лету, во время выполнения. Уж такой гибкости подавляющее большинство ООП-языков не дает. Это т.н. instance-oriented approach, который противопоставляется в чистом Обероне традиционному class-oriented approach. Это связано с тем, что поддержка классов в Обероне построена на расширении типа и процедурных переменных. В традиционных ООП-языках используются процедурные константы (методы). Именно поэтому можно считать чистый Оберон своеобразным ООП-ассемблером.

Это, на мой взгляд, не очень хорошо, ведь, согласно принципам ООП, объекты одного класса одинаково (до некоторой степени) реагируют на события. Если у нас есть объект класса Лампа, и у с ним связана операция Светить -- вряд ли хорошо, если эту операцию мы можем в любой момент подменить на ЖаритьЯичницу. Тем более, что в том же Delphi можно доопределять реакции объектов класса на события с помощью их (событий) обработчиков.


Ваши три пункта, как мне представляется, далеко не самые весомые аргументы в пользу классов. Но, как минимум, некоторые различия между модулями и классами они показывают.

Это аргументы для: Oberon-модуль vs. Класс. Наследование и полиморфизм, отличающие ООП от АТД, не упоминаются сознательно, т.к. в Обероне они есть.

И ещё один аргумент в пользу классов и против Oberon-модулей: класс предстаёт перед программистом в цельном виде. Мы создаём экземпляр класса, и он автоматически включает в себя функциональность своих предков, и обращение к методам предков класса будет таким же, как и к методам объявленным в нём самом. Насколько я понял, в Oberon такое невозможно, и чтобы получить доступ к операциям, связанным с предком используемого типа, нужно явно импортировать модуль, в котором этот предок (и связанные с ним операции) объявлен.

Ответ на »сообщение 3937« (Trurl)
___________________________

>>>В языке Оберон (но не в Оберон-2 и не в КП) можно создавать класс, в котором у любого его экземпляра (забудем на время про производные классы) можно полностью заменить все методы.

А почему это "не в Оберон-2 и не в КП". Это можно сделать даже в C и в PL/1.

Ok. Уточню контекст высказывания. Фраза "можно создавать класс" подразумевает реализацию класса через тип данных (расширяемый) в рамках языка модульного программирования.

Напомню, что в дискуссии обсуждаются модули и классы и что в качестве образцов для сравнения было предложено выбрать Оберон и Java. Для иллюстрации с каждой стороны привлекаются и другие языки соответствующей группы (модульного программирования и ООП).

Я не утверждал, что заменять на лету методы можно только в Обероне. В этом плане C и PL/1 не имеют отношения к высказыванию.

Что касается Оберон-2 и КП, уточняю, что теоретически они могут использовать эту возможность Оберона, хотя практически работают исключительно на уровне связанных процедур (type-bound procedures).

Более того, низкоуровневая возможность Оберона подменять на лету методы (т.е. использовать для этого процедурные переменные) рассматривается как противоречащая вопросам надежности, а потому нерекомендуемая к использованию в языках Оберон-2 и КП, имеющих связанные процедуры.

Более того, в КП это объявляется как устаревшая возможность. И если следовать логике этого языка и восприятия процедурных переменных как goto, то это может привести к отказу от поддержки этой возможности в BlackBox-реализации КП в обозримом будущем.

Ответ на »сообщение 3921« (Руслан Богатырев)
___________________________
>>>В языке Оберон (но не в Оберон-2 и не в КП) можно создавать класс, в котором у любого его экземпляра (забудем на время про производные классы) можно полностью заменить все методы.

А почему это "не в Оберон-2 и не в КП". Это можно сделать даже в C и в PL/1.

Ответ на »сообщение 3917« (Takun)
___________________________


В нем есть понятие аналогичное интерфейсам Явы, но на практике оно не используется (по крайней мере найти примеры в исходниках BlueBottle достаточно сложно).

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


В ETH была диссертация посвященная интеграции Java (как языка) в среду BlueBottle. Наверно возможно сделать то же в отношении других языков этого класса (C#, Eiffel), по крайней мере с той же степенью успешности, с которой это сделано в .NET.

Отлично! Значит, не всё так плохо.
НО! Тут большой вопрос: "Можно ли свести языки в рамках одной системы так, чтобы ни один не потерял присущих ему возможностей?". Мой ответ на него -- "Нет!". (А это, если не ошибаюсь, и в COM не реализовано и в .NET.)

Ответ на »сообщение 3934« (Сергей Губанов)
___________________________

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

Подскажите, как можно это сделать, не зная, что понимается вами под словом "оптимизированный" и под сочетанием "модульные системы"? Если вам трудно сформулировать, дайте, пожалуйста, ссылку на тот источник, где это определяется и c чьим определением вы полностью согласны.


Или вы и этому языку отказываете в праве называться языком модульного программирования?
Ему не отказываю. Он оптимизирован для написания модульных систем.

А причем тогда была реплика относительно расширяемых систем и Вирта?

Повторю свой вопрос: Может ли внутри немодульной системы быть хотя бы один модуль? Да или нет?
Модуль чего? Сначала Вы скажите модулем чего должен быть этот один модуль, вот потом я и скажу: да или нет.

Проблема в том, что в ходе дискуссии я достаточно подробно разбирал, что имею в виду под языковым модулем, операционным модулем и архитектурным модулем. Но у вас совершенно иное представление (как я понимаю). Вот и пытаюсь хотя бы косвенно выяснить, что же вы понимаете под словами "модуль" и "компонент", которыми так свободно "жонглируете".

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

А заодно уточните, пожалуйста, какую систему вы лично считаете модульной? Каковы критерии?

Это нельзя сделать заодно. Тема серьёзная. Заодно только могу указать на примеры: BlackBox, BlueBottle, др. оберон-системы

О, как интересно! Т.е. есть хорошие, правильные системы, и, разумеется, они все сделаны на Оберонах, а есть плохие, нехорошие, неправильные и вообще немодульные системы. На чем написана? На Оберонах -- значит, модульная. Ну а если с помощью BlackBox, то модульная в квадрате.

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

Ответ на »сообщение 3932« (Руслан Богатырев)
Верно ли я понимаю, что стороннему человеку без вашей личной помощи нельзя отличить модульный язык от немодульного?

Не верно.

Или вы и этому языку отказываете в праве называться языком модульного программирования?

Ему не отказываю. Он оптимизирован для написания модульных систем.

Повторю свой вопрос: Может ли внутри немодульной системы быть хотя бы один модуль? Да или нет?

Модуль чего? Сначала Вы скажите модулем чего должен быть этот один модуль, вот потом я и скажу: да или нет.

А заодно уточните, пожалуйста, какую систему вы лично считаете модульной? Каковы критерии?

Это нельзя сделать заодно. Тема серьёзная. Заодно только могу указать на примеры: BlackBox, BlueBottle, др. оберон-системы.

Ответ на »сообщение 3921« (Руслан Богатырев)
___________________________

В языке Оберон ... можно создавать класс, в котором у любого его экземпляра (забудем на время про производные классы) можно полностью заменить все методы. Заменить на лету, во время выполнения. Уж такой гибкости подавляющее большинство ООП-языков не дает.


GOTO тоже дает гибкость.

Именно поэтому можно считать чистый Оберон своеобразным ООП-ассемблером.

А на ассемблерах программировать, вообще-то, избегают.

Ответ на »сообщение 3928« (Сергей Губанов)
___________________________

Модульный язык - язык оптимизированный для написания модульных систем.

Потрясающее определение! Каковы критерии оптимизации, где о них можно почитать? Верно ли я понимаю, что стороннему человеку без вашей личной помощи нельзя отличить модульный язык от немодульного?

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

Ну что вы, я не притворяюсь, а уточняю, что знаете вы. Уточняю в свете ваших утверждений. Скажите, какое отношение язык модульного программирования Modula-2 (созданный проф. Виртом) имеет к расширяемым системам? Или вы и этому языку отказываете в праве называться языком модульного программирования?

Можно ли с помощью модулей создавать немодульные системы? Может ли внутри немодульной системы быть хотя бы один модуль?
Если нет модульной системы, то что такое модуль? Модуль чего?

Повторю свой вопрос: Может ли внутри немодульной системы быть хотя бы один модуль? Да или нет?

А заодно уточните, пожалуйста, какую систему вы лично считаете модульной? Каковы критерии?