Ответ на »сообщение 4015« (Руслан Богатырев)
___________________________
Какие тезисы можно извлечь из вашего пояснения сути модуля и особенностей модульного программирования? См. [ http://www.alexus.ru/russian/articles/design/letter01/page02.htm ]

Попробую это сделать.

С моей точки зрения, данные и код -- суть понятия более низкого уровня (операционного, машинного). В этом контексте можно понять, что вы имеете в виду именно операционный модуль, а не языковой. Если операционный, то что конкретно (какие воплощения) вы подразумевали? Предполагаю, что все же языковой. Вообще говоря, "данные" и "код" в языке объединены и защищены и в рамках процедур (подпрограмм). Процедуры контролируют область видимости и область существования и являются капсулами для "кода" и "данных".
Н-да, читать совсем разучились... Простите, но процитирую оригинальный текст: «Декомпозиция кода заключалась в разделении исходного кода программы на отдельные подпрограммы. Подпрограммы решали две важные задачи: они снижали количество возможных связей между отдельными операторами (локализация кода) и, кроме того, позволяли устанавливать необходимую область видимости для переменных, используемых в подпрограммах (локализация данных). Локализация кода не позволяла произвольно переходить от одного оператора в одной подпрограмме к любому оператору в другой подпрограмме. Вызов подпрограммы приводил к передаче управления только в определённую точку входа, хотя некоторые языки допускали более одной точки входа в подпрограмму.»
То есть, Вы просто повторяете (не вникая в суть). Это Ваше право, но почему же тогда Вы обижаетесь на начетничество?

>> 2. Модуль, в отличие от библиотеки подпрограмм, мог содержать не только подпрограммы, но и данные.
Какие данные? Что подразумевается под словом "данные" -- константы, переменные, типы? Не зря уточняю, ибо как трактовать класс -- как тип (особую форму) или как модуль (особую форму)? Класс -- это код, данные или и то, и другое? С точки зрения области видимости принято делить данные на глобальные, нелокальные (неглобальные) и локальные. Как только в языке появляется модуль, к которому приписываются такие сущности как константы, переменные и типы, возникает возможность представлять нелокальные сущности.
Спасибо... за вольный пересказ. :)

>> 3. Данные, располагаемые в модуле, были глобальными и для модуля и для программы, которая использовала данный модуль.
Вот это положение мне непонятно. Если речь идет об эволюции языков модульного программирования, то скажите, какой конкретно язык вы имели в виду? Если "данные" располагаются в модуле (капсуле), то они могут быть видны снаружи, только если экспортируются. Любые "данные", располагаемые в модуле, нельзя считать глобальными.
Первые модули не имели делений на зоны интерфейса и реализации, если подключался модуль (аналогично библиотеке подпрограмм), то доступным было все, что объявлено в модуле. Деление модуля на отдельные части произошло позже. (Все равно Вы не заставите меня перетряхивать пыльные полки, чтобы дать Вам ссылки...) :)

>> 4. Соответственно критичные к произвольным изменениям данные помещались в зону реализации и были недосягаемы для программы или других модулей. Про эти данные можно сказать, что они были инкапсулированы модулем.
Получается, что "инкапсулированы" означает "полностью скрыты". Рассмотрим ситуацию, когда часть типа данных описана в интерфейсе (типичная ситуация для Оберона в случае частичного экспорта для RECORD), а другая его часть (точнее, весь тип полностью) -- объявлена в реализации. Является ли тип в этом случае инкапсулирован в модуль?
Он является инкапсулированным (включенным), но такая инкапсуляция (сокрытие) не является полной. Другими словами, включение есть, а сокрытия нет. Случай частичного экспорта, по всей видимости, разновидность «частичной беременности».

С эволюционной точки зрения считать модуль прообразом объекта тоже сложно. Ни Simula, ни Smalltalk, ни C++, которые и определили лицо ООП, не проходили стадию использования модуля как конструкции языка программирования. Развитие Simula и Smalltalk шло в параллель с модульным программированием, попросту его не замечая
Не замечая или взаимно обогащая друг друга?

Увы, увы… Чем отличается модуль от класса (и что такое модуль), а также что такое модульное программирование в вашей работе мне найти не удалось
Не удивительно... :)

Очень невежливо. Я задал вполне конкретный вопрос, в ответ вы меня отсылаете куда подальше. Лазить по другим форумам в поисках найти ответ на элементарный вопрос, разумеется, нет никакого желания. Цена вопроса не та.
Вот я о том, же... Если «цена не та», то не лазьте и не смотрите.

>>> Не сможете ли дать конкретные ссылки (пару номеров сообщений в форуме) на высказывания, где “договорились до отмены, как самого «наследования», так и «инкапсуляции»”. Видимо, был невнимателен, не заметил, когда и кто из оппонентов до такого успел договориться.
>> Хм... Пожалуйста, http://www.delphikingdom.ru/asp/talktopic.asp?ID=285&ref=msg&msg=3257#msg3257
Посмотрел на дату и обсуждение. Это другая дискуссия. Странно все это...
Что просили, то и показал... А дискуссия эта, и лица почти все те же (правда, Вас тогда не было).

>> Ха-ха-ха... :) Я понимаю, что Вы человек «энциклопедического склада»... без ссылок и определений Вам трудно воспринимать действительность такой, какова она есть. Но, увы, здесь я Вам ничем помочь не могу.
Понятно. Других работ, кроме ваших, нет.
Хм... А у Вирта Вы тоже выпытывали ссылки, если он высказывал какие-то мысли? Нет, не подумайте, что я равняю себя с Виртом, мне просто интересен принцип «селективного отбора» :)

>> Что ж до моего апломба, то... Вы желаемое выдаете за действительное. Потуги Буча и Ко... просто смешны, чтобы понять это надо просто внимательно прочитать то, о чем они пишут.
Да нет, не выдаю. Просто констатирую, что апломб налицо.
Ха-ха-ха... С каких пор смеяться над глупостью стало признаком апломба? Если мы не будем смеяться на глупостью, то она посмеется над нами...

>>> Давайте зададимся вопросом, что означает слово начетничество:Мне известно два значения:
1. Знания, основанные на механическом, некритическом усвоении прочитанного.
2. Способ усвоения, связанный с догматическим отношением к прочитанному.
>> Совершенно верно, оба определения вполне точны.
Да уж, некорректность свою не хотите признавать. Раз оба определения верны, в чем догма и начетничество, конкретно?
В том, что Вы постоянно цитируете далеко не всегда понимая предмет разговора. Отмотайте «ленту» на несколько дней назад и едва ли не каждое Ваше сообщение являет собой пример начетничества.

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

Есть личные суждения человека, который считает себя много выше других. Никаких работ, отражающих авторскую точку зрения по обсуждаемой теме, порекомендовать не может.
Выше других я себя не считаю. Над глупостями смеялся и буду смеяться (над собственными, в том числе). Ссылок на самом деле не имею... По большому счету, я даже не «читатель»... :)

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

Ответ на »сообщение 4026« (hugi)

Вы называете Windows модульной системой, а когда Вам говорят, что на Delphi (как впрочем и на любом другом языке) легко писать программы для этой системы

ЛЕГКО ПИСАТЬ??????????????????????

Пусть есть сотня Win32 DLL-модулей.
Пусть в каждом из них есть по сотне процедур.
Написать сто раз

moduleHandle := LoadLibrary('MyModule99.dll')

и десять тысяч раз

proc := GetProcAddress(moduleHandle, 'MyProc9999')

это по Вашему легко? Извините, а что тогда сложно?

Но Вы же всё-таки ПО КАКИМ-ТО КРИТЕРИЯМ определили, что они модульные. Так назовите хотя бы эти критерии.

Эти системы расширяются модулями - единицами исполнения. Модули динамически загружаются и выгружаются. Модули с одинаковым интерфейсом взаимозаменяемы.

Ответ на »сообщение 4026« (hugi)
___________________________
>>>Поверьте мне, в динамически-типизируемых языках тоже есть типы данных (они же динамически-ТИПИЗИРУЕМЫЕ).

А ещё их называют бестиповыми. ;-)

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

Модуль – выделенная по тем или иным мотивам часть программы.

Ключевое слово здесь – мотивы. Добиваетесь наглядности — получаете одни модули, экономите время трансляции — другие, хотите расширяемости — третьи, многократной используемости — четвертые, хотите втиснуть программу в область памяти, размер которой меньше размера программы, — пятые и т.д. Конечно, хочется, чтобы модуль порадовал нас сразу всеми своими возможными полезными качествами, но тут мы переходим уже к другой теме…

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

Вот пример обработчика в классическом Обероне:

PROCEDURE Handle(me: Object; VAR msg: Message);

Здесь в числе аргументов обработчика содержатся как сам объект, так и сообщение. Значит, здесь задействованы одновременно две иерархии -- объектов и сообщений.

Вот что интересно. Есть объект. Ему отправляется сообщение. Он его обрабатывает в соответствии с той "схемой коммутации", которая регламентируется его местом (место его родного класса) в общей иерархии классов. Уйдем на время от употребления слов "полиморфизм" и "наследование".

Оберон имитирует это (один из способов) универсальной процедурной переменной (своего рода универсальный метод) с именем handle (типа Handle), которая является одним из полей расширяемого типа (RECORD). Такой тип будучи помещен внутрь модуля специфицирует класс.

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

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

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

Но правда, не припомню, в каком из известных императивных языков есть переменная и нет типов данных.
Любой динамически типизируемый язык. Например, Mathematica.


Поверьте мне, в динамически-типизируемых языках тоже есть типы данных (они же динамически-ТИПИЗИРУЕМЫЕ).


Уточнение/разъяснение

Модульный язык - это язык специально предназначенный/оптимизированный/заточенный для написания модульных систем. Вот тогда когда дельфийские юниты станут единицами исполнения, вот тогда язык Дельфи автоматически превратится в модульный язык. Но тут есть один важный момент. Сам язык-то автоматически превратится, но большинство программ которые на нём уже были написаны автоматически станут неправильными, так как эти программы расчитаны на то что все юниты загружаются при старте программы один раз и выгружаются при её завершении. А теперь-то они при старте программы не загружаются (а загружаются динамически - по требованию, да и программы как таковой теперь вообще нет - вместо неё модульная система), надо будет переписывать старые немодульные программы превращая их в расширения модульной системы.


Интересно у Вас получается! Вы называете Windows модульной системой, а когда Вам говорят, что на Delphi (как впрочем и на любом другом языке) легко писать программы для этой системы (т.е. Delphi заточен под Windows -- с этим, я думаю, никто не поспорит), вы всё равно отказываетесь признать модульность Delphi.

У Вас в корне неверная точка зрения. Нужно различать язык и среду исполнения.


Что и Вы туда же? А определение полиморфизма и переменной Вам дать не надо? Во-первых, я не нанимался определения давать (тут по ним Руслан Богатырёв специализируется). Во-вторых, честно говоря, даже не уверен, можно ли дать строгие формальные определения таким понятиям как модульная система, полиморфизм, переменная. Проще пальцем показывать и говорить, что вот это модульная система, это полиморфизм, а это переменная. Чтобы понять что такое модульная система посмотрите, например, на BlackBox.


Но Вы же всё-таки ПО КАКИМ-ТО КРИТЕРИЯМ определили, что они модульные. Так назовите хотя бы эти критерии.

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

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

Вот важная мысль. Прямое отображение. Добавлю языкового модуля на операционный. Характерно не только для Оберона, но вообще для МП-языков.

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

Зададимся заодно вопросом: что такое класс на уровне компоновки/загрузки и что такое класс на уровне архитектуры? Какие особые свойства, отличные от модуля, классу нужны на уровне, напр., архитектуры?

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

Интрефейсы, случайно, не тот механизм, который Вы так упорно ищете?

Ответ на »сообщение 4016« (AVC)
___________________________
Вот я и задаю Александру Сергеевичу (ASU) вопрос: на каком уровне существует такой "чистый" полиморфизм?
Как его понимать?
Может быть, это вообще "идея чистого разума"? :)
«Чистый» полиморфизм существует:
а) в предметных областях;
б) проектных решениях;
в) в языках (библиотеках) программирования (например, в STL C++).
«Идеи чистого разума»... Я бы сказал, что идея – это признак чистого разума (неискаженного восприятия). Правда, идею не всегда легко отличить от домысла. Но вряд ли стоит развивать эту тему...

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

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

Скажите, может ли один и тот же класс в языке Eiffel иметь несколько экземпляров (своих представителей)?

Класс не может. Объекты класса мы сейчас вроде не рассматриваем.

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

Пропустил (своих представителей) :(. Я имел в виду, что если отбросить ООП и порождение объектов на базе классов, то сам по себе класс существует в единственном экземпляре. Пример Math (или что-то в этом роде). Действительно, классы не существуют в объектном коде и во время выполнения программы, но (по Парнасу) это допустимо и, с точки зрения оптимизации, желательно.
Собственно пост был в большей степени о том, что часть работы Парнаса, описывающая реализацию модулей, ближе к по идеологии к С++, Эйфелю и пр. Эйфель был упомянут, так как предполагает наиболее агрессивную оптимизацию. В то время как для Обероновского подхода характерно (относительно) прямое отображение текста программ (в том числе модулей) в объектный код.

P.S. (Инет тормозит... уже третий раз пост переписываю :( )