Ответ на »сообщение 4187« (ASU)
___________________________
>>>Если найдется склад, который ни «демпфирует» входные и выходные потоки, то я пойду готовить салат к новогоднему столу... из своей шляпы.
Например заброшенный склад :)
Приятного аппетита :Р

>>> Модель либо отражает смысл, либо нет...
Модель не может отражать ВЕСЬ смысл. Смысл ведь тоже субъективное понятие. Для многих в наших разговорах вообще никакого смысла. А для нас есть, причем разный.

>>>Это длинный путь... в никуда.
Последовательная декомпозиция цели - очень мощный инструмент как для анализа систем, так и для их синтеза.

>>>Вот что интересно в этой связи... наши модели сейчас применяют в таких областях, о которых я не только не думал, но и которые я знаю весьма плохо. И применяют... вполне успешно
Вполне возможно, что Вам удалось создать модель для решения определенных задач на самых разных объектах. Вот только не ВСЕХ задач.

>>>боюсь, что это могут расценить, как рекламу.
Не надо бояться, скорее расценят как повод для обсуждения, что на базарной площади поощряется.

Всех с Новым Годом.

Ответ на »сообщение 4188« (Сергей Губанов)
___________________________
>>> Тогда это будет монолитная система. В ней модулей нет. Для ее написания Вам понятие модуля не нужно - вполне хватит: namespace, class, unit.

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

Ответ на »сообщение 4188« (Сергей Губанов)
___________________________
>>>Вы взаправду верите в существование модулей без модульных систем?
При чем тут вера? Существуют модульные тексты, модульные алгоритмы, модульные игрушки и т.д. и т.п. Все это конечно можно назвать модульными системами, но мне кажется Вы используете этот термин в более узком смысле.
>>>Тогда это будет монолитная система. В ней модулей нет.
А вот и не обязательно :) Представьте себе, что загрузка производится путем вставления отдельных плат (сколько такого было). Разработчику необходимо разбить код на части примерно одинакового размера, диктуемого не особенностями алгоритма, а объемом памяти на плате.
>>>Язык - это одно, алгоритмы - другое, реализация - третье, модули - четвёртое. Вы же всё это в одном предложении непостижимым образом связали.
Я и хочу показать, что модули понятие ортогональное - модульный подход приложим к любым системам, в том числе вообще не имеющем отношения к программированию и компьютерам.

Ответ на »сообщение 4186« (Сергей Перовский)
Это Вы ведете беседу о "модульных системах", а остальные о модулях в самых разных языках и системах программирования.
Вы взаправду верите в существование модулей без модульных систем?

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

будет "загружена" навсегда
Тогда это будет монолитная система. В ней модулей нет. Для ее написания Вам понятие модуля не нужно - вполне хватит: namespace, class, unit.

С наступающим Вас
Спасибо, Вас тоже!

Ответ на »сообщение 4181« (Сергей Перовский)
___________________________
Итак, «соль» склада – это демпфирование входных и выходных потоков.
Для организации, чей склад, это, безусловно, так. А с точки зрения института генерального плана это коробка, занимающая определенную территорию, потребляющая энергию и провоцирующая транспортные потоки
Безусловно... нет. Достаточно много складов – это пустырь обнесенный забором. Посмотрите, например, на ГОКи (горно-обогатительные комбинаты), их склады готовой продукции (окатыши) – расположены под открытым небом... Нет никакой «коробки», посмотрите на «рудные дворы» металлургических предприятий... Площадки под открытым небом... безо всякой «коробки»... склады, склады, склады... А еще есть склады расположенные в бывших рудниках, и там нет никаких коробок... А причалы... Это раз.
Два. Склад никогда не провоцирует транспортные потоки. Склад пассивен, при правильной организации работ, склад даже не должен порождать документов. Все приходы и расходы инициируются извне (включая акты оприходования излишков и акты списания).
В чем Вы правы, так это в том, что хранение имеет свою цену, в которую входят стоимости обслуживания хранимых материалов, расходы на электроэнергию, расходы на обслуживание оборудования, заработная плата складских рабочих; возможно(!), аренда земли, помещений и того же оборудования и пр. Но что это меняет в том, о чем я говорил ранее? Суть склада осталась та же самая.
Да, строительная организация, которая строит помещение под склад, смотрит на него [склад] иначе... как на строительный объект/здание/сооружение. Но это совершенно верно, для них – это сооружение, и им совершенно безразлично, будет ли в этом помещении склад, производство или нечто иное. Склад и здание/сооружение – совершенно разные понятия. Если склад переедет в другое помещение, он не перестанет быть складом, а помещение – помещением. Не надо смешивать красное с круглым...

Всячески поддерживаю идею об учете семантики
Хм... Это похоже на тост... В любом случае за это стоит выпить! :)

Но "давайте без фанатизьму".
Разумно...

Никакая модель не может быть абсолютно адекватна объекту. Модель хороша или плоха в зависимости от того, позволяет она решать требуемый класс задач с требуемой точностью или нет
Фи... Сколько намешано... правильных слов... Полная адекватность модели объекту означает их тождество. «Хорошесть» модели не означает ее способность решать требуемый класс задач (мало ли кто чего потребует от модели, говорят, что и микроскопом гвозди забивали...). Если вернуться к семантике, то «хорошесть» модели – это «рыба второй свежести»... Модель либо отражает смысл, либо нет... И все. Если найдется склад, который ни «демпфирует» входные и выходные потоки, то я пойду готовить салат к новогоднему столу... из своей шляпы.

Я, конечно, всегда стараюсь идти описанным путем - анализировать цели системы
Это длинный путь... в никуда. Не увлекайтесь прогулками по этому пути... если, конечно, Вы не собираетесь повторить подвиг Ивана Сусанина.

Конечно, надо пытаться построить иерархию так, чтобы поддерживать по возможности широкий класс задач. Меня тоже раздражают склепанные под очень частный случай системы, которые проще выбросить, чем переделать. Но я отдаю себе отчет, что как бы не старался, найдутся задачи, для которых моя модель не подходит
Хм... Вот что интересно в этой связи... наши модели сейчас применяют в таких областях, о которых я не только не думал, но и которые я знаю весьма плохо. И применяют... вполне успешно. То есть, ситуация диаметрально противоположная той, которую описываете Вы. Я могу проиллюстрировать это совсем недавними примерами, но... боюсь, что это могут расценить, как рекламу. Потому, если можете и хотите, то поверьте на слово...

Ответ на »сообщение 4185« (Сергей Губанов)
___________________________
>>>Но мы тут разьве не о модульных системах и языках предназначенных для их написания беседу ведём?
Это Вы ведете беседу о "модульных системах", а остальные о модулях в самых разных языках и системах программирования. Одно другому разумеется не противоречит. Но не надо постоянно повторять "нет Бога, кроме Аллаха".
Если язык рассматривать, как средство выражения алгоритмов, безотносительно к какой либо реализации, то там понятие модуля будет несколько другим. Поскольку мы хотим описывать не отдельные алгоритмы, а множество алгоритмов, очень перспективным представляется модульный подход. А что там будет на уровне реализации, в данном контексте абсолютно не важно. Может вся совокупность алгоритмов будет реализована в ПЗУ в адресной памяти процессора и таким образом будет "загружена" навсегда. А может я вообще использую компилятор для микропрограммирования. Мир велик и встречается в нем всякое.

С наступающим Вас

Ответ на »сообщение 4182« (Сергей Перовский)
Пример не показательный: достаточно предусмотреть у класса "Человек" свойство "Профессия" объектного типа и присваивайте динамически. Для полноты картины это может быть список профессий. Не потребуется ни интерфейсов, ни множественного наследования - канонический случай ООП.

Хм... Это Вы к чему? А вот это: »сообщение 4107« , »сообщение 4108« тогда что???????????

Ответ на »сообщение 4183« (Сергей Перовский)
Давайте не будем монополизировать слово, имеющее очень много смыслов.
Давайте не монополизировать. Но мы тут разьве не о модульных системах и языках предназначенных для их написания беседу ведём? А если так, то нет у "модуля" в этом смысле другого смысла :-)))))))))

Ответ на »сообщение 4184« (Trurl)
Вот, например, Модула. Общепризнано считать его модульным языком. Но в Вашей терминологи это не так.

Почему?

Ответ на »сообщение 4179« (Сергей Губанов)
___________________________
Вот, например, Модула. Общепризнано считать его модульным языком. Но в Вашей терминологи это не так.

Ответ на »сообщение 4179« (Сергей Губанов)
___________________________
>>>Любая другая "модульная" конструкция языка не совпадающая с модулем системы, модулем не является. Она является чем-то другим: классом, пространством имён, юнитом, куском текста и т.п., но не модулем.
Давайте не будем монополизировать слово, имеющее очень много смыслов.
Вот например:
Определения модуль в интернете:
• абстрактная единица модели документа, выражаемая как фрагмент DTD и используемая для объединения объявлений разметки с целью повышения гибкости, изменяемости, возможности повторного использования и понимания конкретных логических или семантических структур.
www2.stack.ru/~julia/XHTML/xhtml-modularization/terms.html
• Единица кода, служащая строительным блоком физической структуры системы; программный блок, который содержит объявления, выраженные в соответствии с требованиями языка и образующие физическую реализацию части или всех классов и объектов логического проекта системы. ...
khpi-iip.mipk.kharkiv.edu/library/case/buch/glossary.html
• архитектурный термин (радиус комля колонны, служащий мерилом ее высоты).
www.rvb.ru/18vek/knyazhnin/02comm/dict.htm
• Набор из одной или большего количества связанных функций, реализующих определенную подсистему аутентификации, собранный в один (обычно динамически загружаемый) двоичный файл, идентифицируемый по имени.
www.freebsd.org/doc/ru_RU.KOI8-R/articles/pam/pam-terms.html
• оплаченные Заказчиком, либо его представителем материалы в СМИ.
www.ecro.ru/monitoring/dictionary/index.phtml
• часть ядра, которую можно присоединять и отсоединять от ядра (тем самым, загружая/выгружая из памяти) когда она не требуется. Модули позволяют экономить память и увеличить гибкость системы. Драйверы устройств для Linux обычно распространяются в виде модулей.
www.i2r.ru/static/212/out_16355.shtml
• единица длины, являющаяся в оформлении изданий основой для графических построений.
www.amd-online.ru/12.htm
• (Module) - оформленный специальным образом блок кода.
www.whatis.ru/glos/r12.shtml
• определяется заголовком модуля и телом модуля, связанным с этим заголовком. Для одного и того же заголовка модуля может существовать несколько тел. Заголовок и тело определяют модуль. ...
www.iis.nsk.su/preprints/Monog/MONOGR/node4.html
• разновидность вторичного защитного покрытия световодов, используемая в магистральных кабелях внешней прокладки. Представляет собой трубку из пластика различной жёсткости диаметром порядка 2-3 мм, в которой свободно уложены один или несколько световодов.
www.rusoptika.ru/slovar.html
• (лат. modulus — «мера») — в пластических искусствах условная исходная мера, принятая для выражения кратных отношений размеров целого и составляющих его частей.
scit.boom.ru/iskustvo/iskustvo_italii002.htm
• функционально самостоятельная часть программной среды.
edu.km.ru/projects/km_school/km_school_kurs_slovar.htm
• Реализация, обычно программная, протокола или других процедур
skif.bas-net.by/bsuir/base/node344.html

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

Ответ на »сообщение 4179« (Сергей Губанов)
___________________________
>>>Но я или Вы, как уже созданные объекты класса "Человек", освоить роль/профессию почтальона можем (динамически).
Пример не показательный: достаточно предусмотреть у класса "Человек" свойство "Профессия" объектного типа и присваивайте динамически. Для полноты картины это может быть список профессий. Не потребуется ни интерфейсов, ни множественного наследования - канонический случай ООП.