Здравствуйте, Сергей Губанов, Вы писали:
СГ>А то что модульность УЖЕ БЫЛА РЕАЛИЗОВАНА в языке Modula Вы значит не в курсе?
Ну и что? Модульность еще на ZX-Spectrum была. Да и до этого тоже — можно смело считать это каменным веком программирования. Который начался, когда люди научились хранить программы на внешних носителях и собирать их из частей
Единственным новшеством у Модулы можно считать поддержку модульности на уровне языка. Но это, знаете ли, просто эволюционное развитие. Может быть, в Модуле такая поддержка появилась впервые. Но считать из-за этого, что все последующие языки произошли от Модулы — это просто чушь.
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[30]: Размер структурной единицы (Грануляция системы)
Здравствуйте, VladD2, Вы писали:
VD>Вот это и чуш. Зачем мне 50 модулей для создания одного приложения? Мне достаточно ОДНОГО исполняемого файла и 1-5 библиотек.
А затем, что:
1) 30-40 из них можно использовать потом повторно для других приложений. Один раз написанный модуль становится частью всей операционной системы навсегда.
2) Сложность системы (внесение изменений) описывается U-образным графиком зависимости от размера грануляции тех структурных единиц из которых эта система собрана:
Если в системе много мелких структурных единиц, то значит между ними много связей, когда будешь вносить изменения — замучаешься эти связи отслеживать — сложность растет вместе с ростом количества связей.
Если структурных единиц мало, но они крупные, то замучаешься менять целую большую единицу — сложность опять растет вместе с ростом размера структурной единицы.
Есть промежуточная стадия, когда размер структурной единицы еще не так велик чтобы она считалась сложной, но и количество структурных единиц тоже не на столько велико чтобы запутаться в них. В этом случае сложность системы минимальна.
Модули надо делать именно такого "не большого и не малого" размера.
Re[31]: Размер структурной единицы (Грануляция системы)
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>>Вот это и чуш. Зачем мне 50 модулей для создания одного приложения? Мне достаточно ОДНОГО исполняемого файла и 1-5 библиотек.
СГ>А затем, что:
СГ>1) 30-40 из них можно использовать потом повторно для других приложений. Один раз написанный модуль становится частью всей операционной системы навсегда.
Ага, Вася Пупкин напишет модуль Foo, с мегаметодом make_foo и появится он уже в следующей версии Windows
Имеющий уши, да услышит.
Вот еще один интересный вопрос. Каким образом ухитряется работать UI в Windows? Окна обмениваются какими-то мистическими сообщениями, и нигде нет ни одного указателся на функцию! Ну просто безобразие, ересь сплошная! Да еще и написано это на С++! (Изыди, нечистая сила!)
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Вот она свои дела доделывает-доделывает и тут вдруг понимает, что надо бы вызвать процедуру из EXE, ан нет — не может. А была бы у нее процедурная переменная связанная с той процедурой, так запросто бы смогла.
К>Может. Подумай как. Не придумаешь — завтра расскажу.
Ну-у, она, например, может письмо написать и послать его EXE-шнику по e-mail. Экзешник это письмо получит и сделат что надо.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Нету в расширяемых модульных система EXE!!!!!! В них есть только модули. Надо вызвать процедуру из какого-то модуля — загружаешь этот модуль в память и вызываешь эту процедуру. Вот и все. Все так просто!!!
СГ>Нету в расширяемых модульных системах "программ" или "проектов". Есть только сама система и куча модулей расширяющих возможности этой системы. Роль "проекта" может играть, например, какой-нибудь модуль-фасад, импортирующий нужные ему модули, о которых другие модули ничего не знают.
Если провести параллели с многозадачностью, то ты говоришь о "корпоративной" модульности, когда всё — рантайм, библиотеки, точки входа — вообще всё — свалено в кучу, пусть даже и по каталогам рассовано.
Добавил детальку — фактически, получил новую систему. Она самодостаточна: компилятор — это одна из деталек, и результат его работы — идёт туда же.
Поэтому эта штука и названа BlackBox, хотя более правильное ей имя — SandBox, то есть песочница.
Но следует заметить, что ничего нового здесь не сказано. Многие системы так поступают — да вот хотя бы Lisp, Forth, вроде бы Smalltalk (пусть меня поправят насчёт смолтока).
А есть ещё "жёсткая" модульность, где всегда можно провести границу: вот это системные библиотеки, а вот сторонние, а вот мои собственные — причём библиотеки из разных пакетов нормально сосуществуют, не заползая в область видимости друг друга.
Перекуём баги на фичи!
Re[31]: Размер структурной единицы (Грануляция системы)
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Есть промежуточная стадия, когда размер структурной единицы еще не так велик чтобы она считалась сложной, но и количество структурных единиц тоже не на столько велико чтобы запутаться в них. В этом случае сложность системы минимальна.
А еще есть такая вещь, как иерархическая организация модулей. Но это, видимо, тоже ересь и настоящим программистам не пристало заниматься такими вещами.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Вот она свои дела доделывает-доделывает и тут вдруг понимает, что надо бы вызвать процедуру из EXE, ан нет — не может. А была бы у нее процедурная переменная связанная с той процедурой, так запросто бы смогла.
К>>Может. Подумай как. Не придумаешь — завтра расскажу.
СГ>Ну-у, она, например, может письмо написать и послать его EXE-шнику по e-mail. Экзешник это письмо получит и сделат что надо.
Нет, это всего лишь разновидность последовательного канала между активным сервером в EXE и клиентом, размазанным по EXE и DLL, о котором мы уже говорили.
Загадка: чем первый вызов функции DLL (в механизме, который я описал) отличается от второго? От, возможно, третьего, четвёртого, пятого?..
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>>Вот она свои дела доделывает-доделывает и тут вдруг понимает, что надо бы вызвать процедуру из EXE, ан нет — не может. А была бы у нее процедурная переменная связанная с той процедурой, так запросто бы смогла.
К>>>Может. Подумай как. Не придумаешь — завтра расскажу.
СГ>>Ну-у, она, например, может письмо написать и послать его EXE-шнику по e-mail. Экзешник это письмо получит и сделат что надо.
К>Нет, это всего лишь разновидность последовательного канала между активным сервером в EXE и клиентом, размазанным по EXE и DLL, о котором мы уже говорили. К>Загадка: чем первый вызов функции DLL (в механизме, который я описал) отличается от второго? От, возможно, третьего, четвёртого, пятого?..
Понял.
В тот момент когда DLL понимает что ей нужно вызвать кое-какую процедуру из EXE, она запоминает свой контекст и возвращает управление обратно в EXE вместе с просьбой выполнить ту процедуру. Когда EXE, выполнив просьбу, опять вызывает функцию из DLL, то она восстанавливает свой контекст и думает что ей делать дальше.
Вобщем, получается ручная эмуляция работы стека вызовов процедур.
Re[32]: Размер структурной единицы (Грануляция системы)
Здравствуйте, Дарней, Вы писали:
Д>А еще есть такая вещь, как иерархическая организация модулей. Но это, видимо, тоже ересь и настоящим программистам не пристало заниматься такими вещами.
Граф импорта модулей друг другом ацикличен — вот Вам иерархическая структура. Модули ВСЕГДА организованы иерархически.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Не, ну каково, а? Естественно, что в случаях СТАТИЧЕСКОЙ ЛИНКОВКИ не нежен ДИНАМИЧЕСКИЙ ЗАГРУЗЧИК.
К>Вот именно, о чём спорим? О том, что К>
2) COM-овские объекты загружает специальный COM-овский загрузчик, являющийся средой исполнения COM-объектов
Ну, раз такое дело, то как бы, приношу свои извенения за доставленные неудобства, без процедурных переменных таки можно организовать то, что я думал что организовать нельзя.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В тот момент когда DLL понимает что ей нужно вызвать кое-какую процедуру из EXE, она запоминает свой контекст и возвращает управление обратно в EXE вместе с просьбой выполнить ту процедуру. Когда EXE, выполнив просьбу, опять вызывает функцию из DLL, то она восстанавливает свой контекст и думает что ей делать дальше.
СГ>Вобщем, получается ручная эмуляция работы стека вызовов процедур.
Конечно!
Причём с возможностью закрутки-раскрутки (если наши функции не влияют на состояние, то мы можем многократно вызвать их с одним и тем же "дампом памяти" и получить одинаковый результат).
Можно заметить, что для возвращения из процедуры — вызывающая сторона должна положить на стек адрес возврата. Это может показаться процедурной переменной, но на деле ею не является: у программиста нет возможности к ней доступиться (кроме хака), да и суть другая (точка входа vs. точка возврата).
Естественно, что в обычных ситуациях делать такую механику — смысла нет. И языки так или иначе поддерживают более удобные способы косвенного вызова — будь то процедурные переменные (известные в С/С++ как указатели на функции), прокси, интерфейсы, делегаты, лямбды...
Что интересно — все они друг через друга могут быть реализованы. Это не тождественные, но эквивалентные (равномощные, если с латыни перевести) инструменты.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>>В Дотнете, на базе которого создан Шарп, модульность — это один из основополагающих принципов.
СГ>Все верно. И что? Какой вывод? Например, такой: Дотнет создан на базе опыта накопленного оберонами (с 1985 года — разработка первого оберона).
Опыта у Оберона нет и быть не может, так как он никогда не использовался в широкой практике. Полезные идеи Оберона (а вернее еще Паскаля) были включены во множество современных языков. В том числе и в Шарп. При этом языки вроде Шарпа и Явы проверены вренменем, обладают как минимум не меньшей безопасностью, и значительно более гибки, удобны и функциональны. По этому, учить нужно именно им. А Оберон вообне не нужен в этом мире. Для старта достаточно Паскля, а то и какого-нибудь Руби с Питоном. Ну, а современному ООП нужно обучать именно на Шарпе или Яве.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Вот еще один интересный вопрос. Каким образом ухитряется работать UI в Windows? Окна обмениваются какими-то мистическими сообщениями, и нигде нет ни одного указателся на функцию!
Здравствуйте, Сергей Губанов, Вы писали:
СГ>1) 30-40 из них можно использовать потом повторно для других приложений. Один раз написанный модуль становится частью всей операционной системы навсегда.
Дык и 1-5 можно. Если код универсальный он выносится в библиотеки.
СГ>2) Сложность системы (внесение изменений) описывается U-образным графиком зависимости от размера грануляции тех структурных единиц из которых эта система собрана: СГ>
СГ>Если в системе много мелких структурных единиц, то значит между ними много связей, когда будешь вносить изменения — замучаешься эти связи отслеживать — сложность растет вместе с ростом количества связей.
Выглядит очень умно. Но полная чушь, просто по тому что тут много народа писало действительно сложные проекты на том же Шарпе и дотнете. Так вот никаких проблем нет.
Другими словами нет никакой зависимости между мелкостью модулей, легкосью внесения изменний и стркукурными еденицами. Структурной еденицей является файл исходников. Правится он на раз. При компиляции несклько исходников превращаются в один модуль. Модули связываются между собой так как им необходимов. В итоге все просто, быстро, и я бы даже сказал, пушисто.
СГ>Если структурных единиц мало, но они крупные, то замучаешься менять целую большую единицу — сложность опять растет вместе с ростом размера структурной единицы.
А зачем связывать модули и исходные файлы. Я правильно понимаю, что ты оссоциируешь модуль с исходным файлом?
СГ>Есть промежуточная стадия, когда размер структурной единицы еще не так велик чтобы она считалась сложной, но и количество структурных единиц тоже не на столько велико чтобы запутаться в них. В этом случае сложность системы минимальна.
СГ>Модули надо делать именно такого "не большого и не малого" размера.
В общем, ты так и не убедил тут никого в целесообразности создания микроскопических модулей. А применение неопределенных понятий вроде "структурной единицы" делает все еще более туманным и непонятным.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Размер структурной единицы (Грануляция системы)
Здравствуйте, Дарней, Вы писали:
Д>А еще есть такая вещь, как иерархическая организация модулей. Но это, видимо, тоже ересь и настоящим программистам не пристало заниматься такими вещами.
Да а нафиг оно упало? Модулей то всего ничего... 100-200 на проект. Та их и в плоском списке можно деражать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>не надо грязи. я то прекрасно знаю, что это такое Д>это тот самый свитч, про который наш многоуважаемый оппонент доказывает, что он не может работать
Ваш многоуважаемый оппонент доказывал совсем другое. Перечитай топик ещё раз.
Речь шла о том, что процедурные переменные являются незаменимой частью высокоуровневого языка, их отсутствие сократит размерность пространства возможных проектных решений, реализуемымых на данном гипотетическом языке. Кодт доказал
Перекуём баги на фичи!
