Ответ на »сообщение 4178« (ASU)
>>>Итак, «соль» склада – это демпфирование входных и выходных потоков.
Для организации, чей склад, это, безусловно, так. А с точки зрения института генерального плана это коробка, занимающая определенную территорию, потребляющая энергию и провоцирующая транспортные потоки.
Всячески поддерживаю идею об учете семантики.
Но "давайте без фанатизьму".
Никакая модель не может быть абсолютно адекватна объекту. Модель хороша или плоха в зависимости от того, позволяет она решать требуемый класс задач с требуемой точностью или нет.
Я, конечно, всегда стараюсь идти описанным путем - анализировать цели системы. Конечно, надо пытаться построить иерархию так, чтобы поддерживать по возможности широкий класс задач. Меня тоже раздражают склепанные под очень частный случай системы, которые проще выбросить, чем переделать. Но я отдаю себе отчет, что как бы не старался, найдутся задачи, для которых моя модель не подходит.

Ответ на »сообщение 4177« (Как слышно? Прием!)
___________________________
Если слепой "снимет повязку с глаз" ничего не изменится. Поэтому нельзя себя лишать одного из чувств - осязания. Страшно представить себя без него.
Для слепого ничего не изменится, но как быть со зрячими? Надо ли им все время изображать слепцов?

"Смешно или грустно ... играть в жмурки?"
А Вы попробуйте проверить это опытным путём на Новый год в приятной компании.
Однозначно - смешно и весело!
Есть праздники и есть будни. Есть работа и есть развлечение. То что уместно (забавно и весело) в одном случае, неуместно в другом... Красить мир одной краской - надо ли...

»сообщение 4115« (hugi) Я считаю, что модуль - он не только модуль системы, но и конструкция языка, и эти два понятия по большому счёту независимы.

Естественно, что в модульном языке обязательно есть синтаксическая конструкция соответствующая модулю системы. Иначе как бы тогда этот язык был бы приспособлен/удобен/предназначен для написания модульных систем? Любая другая "модульная" конструкция языка не совпадающая с модулем системы, модулем не является. Она является чем-то другим: классом, пространством имён, юнитом, куском текста и т.п., но не модулем.

»сообщение 4115« (hugi) Таким образом, Oberon одновременно заточен и не заточен, модульный и не модульный, в чём и заключается противоречие.

Если что-то предназначено для одного, но не предназначено для другого, то это не противоречие.

»сообщение 4116« (hugi) Утверждать, что x -- переменная Вам позволяет тот факт, что x может менять значение в течение времени своего существования. Естественно, типы здесь ни при чём.

О чём я и говорил. Но Вы стали спорить...

»сообщение 4120« (hugi) ...К тому же, раз уж на то пошло, позволю себе отметить, что описанная Вами стратегия более естественно реализуется с помощью интерфейсов, а не агрегатов...

Интерфейсов? Это тех, которые в Delphi, Java, C# обозначаются interface? Нет, увы с помощью interface это никак не реализуемо. Дело в том, что interface жестко прописывается на уровне класса - все объекты этого класса поддерживают описанные в классе интерфейсы. Если класс "Человек" реализует интерфейс "Почтальон", то это будет означать, что все объекты этого класса (все люди) по своему рождению - в том числе и почтальоны. Но это не так. Я, например, не почтальон, но человек. "Почтальон" - это роль или, если хотите профессия, которую может динамически приобрести конкретный объект - человек, который по рождению (при конструировании) не предполагал даже, что когда-то в будущем будет исполнять такую роль. interface - динамически приобрести нельзя, он либо прописан в определении класса либо не прописан. Повторяя ASU - Вы не можете поменять класс у уже созданного объекта. Но я или Вы, как уже созданные объекты класса "Человек", освоить роль/профессию почтальона можем (динамически).

Ответ на »сообщение 4175« (Горбунов-Посадов)
___________________________
Каноническая триада ООП эклектична, ее составляющие весьма неравноценны
Разговор о равноценности... бесперспективен. Ценность понятие относительное, а, следовательно, и равноценность тоже... Помните... «Коня, полмира за коня!»...
Поэтому и результаты анализа, сделанного на сравнении соврешенно разных «китов» ООП, не вызывает доверия.

Инкапсуляция. Ни у кого из участников форума не вызвала сомнений ведущая роль инкапсуляции. Инкапсуляция необходима, постоянно и энергично используется и весьма продуктивна.
Инкапсуляция (заключение «в капсулу», сокрытие) обеспечивает защиту объекта, а защита (при соблюдении интерфейсов!) позволяет делать производить замены одного объекта на другой. Если бы программист привязал свой код к «внутренностям» какого-то объекта, то заменить этот объект на другой без переписывания кода будет, увы, невозможно. А переписывание кода сопряжено с большими усилиями, возможностью внесения ошибок, поддержкой старых средств разработки и пр.

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

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

"С точки зрения энергетика, диспетчера и таможенника аэропорт имеет совершенно
различные структуры. И все правы :)"

При древовидной топологии оно так. Представим себе топологию системы в виде
паутины. Выбирая в качестве базовой точки некоторую, более близкую субъекту,
покрыть такой граф деревом можно различными способами. Отсюда и вопросы
"Что будет выступать в качестве базового класса? Как будет развиваться ... иерархия?"
и ситуация со сказкой «про белого бычка» при разработках. Дерево классов -
это конкретная и в этом смысле произвольная или случайная топология, иерархия
от программирования в ООП парадигме наложенная на паутину системы объектов.
Наследование при построении дерева классов ведет к одеревенению системы.
Конечно, надо различать организацию объектов в языке и структуру описываемой
системы, но инструмент обязывает и систематически сворачивает мысль на накатанную
колею. Для "practitioners of programming" надо иметь целью построение паутинной
топологии, а не случайного дерева, образованного диким способом, что должно быть
закреплено средствами разработки.
Практика текстового программирования привела к линейной топологии. Попытки
структурировать (goto) - неуклюжи и harmful. Более успешна организация  с помощью
процедур с топологией дерева. Появившиеся объекты ООП  унаследовали дерево,
хотя приобрели зачатки организации в более развитую топологию в виде стандартного
интерфейса.

Модули Оберона представляют гению от программирования составлять любые топологии,
но это хорошо, если у Вас к дистрибутиву прилагается клон мозга Вирта. Или многолетний
опыт и система умолчаний, образующая культуру, своего рода IDE. (Что повышает стоимость
полного владения системы разработки)  А для рядового разработчика когда "language
described in only 16 pages" проявляется ситуация, когда теряются в базовые понятия,
которые были опущены по умолчанию, например, понятии модуля. "Дополнительные
степени свободы для разработчика" хороши в меру.
Как известно, наибольшее количество степеней свободы имеет хаос.

Поэтому со стороны классического ООП - долой наследование. Со стороны Оберона -
даёшь библиотеку стандартных модулей из частоты употребления предметных объектов
и IDE разработчика без атавизма древовидной топологии. И, ради Бога, побольше
структурированного, контекстно привязанного описания.

Полезно критически подходить к устоявшимся взглядам. Дорогущие сплит системы
обеспечивают кратность вентиляции равную нулю, что противоречит ГОСТу и, в конце
концов, интересам Вашего самочувствия и производительности программирования.
Только слепой не увидит в жаркий летний день, проходя мимо банка, утыканного
теплообменниками сплит систем, открытые фрамуги.
Если слепой "снимет повязку с глаз" ничего не изменится. Поэтому нельзя себя лишать
одного из чувств - осязания. Страшно представить себя без него.
"Смешно или грустно ... играть в жмурки?"
А Вы попробуйте проверить это опытным путём на Новый год в приятной компании.

Однозначно - смешно и весело!

Ответ на »сообщение 4175« (Горбунов-Посадов)
___________________________

приходится "махать кулаками после драки".

Ваше summary можно только приветствовать.

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

Каноническая триада ООП эклектична, ее составляющие весьма неравноценны.

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

Наследование, иерархия. Широко применяющийся, массовый, но скучный и малопродуктивный механизм. На мой взгляд, тут надо брать пример с соседствующей с программистским инструментарием, но существенно более развитой технологически области -- с СУБД. Там иерархия четко и недвусмысленно задвинута на подобающее ей периферийное место.

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

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

Ответ на »сообщение 4173« (ASU)
___________________________
>>>Болт остается болтом, независимо от того, что он крепит... Не важно (в данном рассмотрении), к какому узлу мы «прикрутили» болт, он от этого не перестанет быть болтом,  его класс от этого не изменится.

А если мы его забили?

Ответ на »сообщение 4171« (Сергей Перовский)
___________________________
Есть понятие иерархии. Не всякая иерархия относится к классификации. Например, иерархии «вложения», «подчинения» не являются классификацией.
В основе вложения и подчинения неявно лежит классификация. Если мы рассмотрим дерево разузлования конструкции, то отнесение деталей к тому или иному узлу может быть различным в зависимости от задачи.
Административная структура подчинения тоже построена на основе группирования по функциональным или целевым признакам, т.е. тоже некоторой классификации.
Болт остается болтом, независимо от того, что он крепит... Не важно (в данном рассмотрении), к какому узлу мы «прикрутили» болт, он от этого не перестанет быть болтом,  его класс от этого не изменится. Изменение положения в иерархии вложений не изменяет класс элемента или агрегата. Это относится и к иерархии подчинения. Конструкторский отдел останется конструкторским отделом, подчиняясь сначала ОГМ (отделу главного механика), а затем главному инженеру.
IMHO, Вы напрасно оперируете «функциональными и целевыми признаками»... это может внести путаницу. Попробуйте рассуждать несколько иначе, например, так... у предприятия есть потребность (в новой конструкции изделия – продукции данного предприятия) и эта потребность можно удовлетворить разными способами. Можно дать задание своему конструкторскому отделу, можно заказать разработку на стороне, а можно купить готовое решение (лицензию на производство). То есть, можно сказать, что есть роль «разработчик продукции», и в этой роли могут выступать разные «сущности»... Но бессмысленно выстраивать «иерархию наследования» для «разработчиков продукции». Что будет выступать в качестве базового класса? Как будет развиваться данная иерархия?.. Тупик.

«Наследование» в ООП основано на выявлении родовых (общих свойств), которые передаются от суперкласса его подклассам. Иными словами, наследование в ООП имеет в своей основе иерархическую классификацию, описывающую передачу родовых свойств. А, следовательно, говорить о произвольном формировании иерархической классификации при наследовании в ООП – моветон (или глупость, или обман – нужное подчеркнуть)
А никто и не говорит о ПРОИЗВОЛЬНОМ. Формирование иерархии зависит от того С КАКОЙ ЦЕЛЬЮ она производится
Множественность целей позволяет сделать произвольный выбор среди них и получить... произвольную иерархию. Один слепой, потрогав ногу слона, уверял, что слон похож на дерево, другой слепой, потрогав хобот, уверял, что слон похож на змею... Если не попытаться понять смысл (увидеть слона целиком), то... остается только воспользоваться отдельными признаками (пощупать какую-то часть) и на этом основании встроить слона в свою(!) классификацию. Придет другой слепой и построит свою классификацию. Это увлекательно... наверное. Но попробуйте представить себе на мгновение такую картину: все давно сняли повязки с глаз, а кто-то один ощупывает слона, выкрикивая предположения... Смешно или грустно?..
Хочется верить, что когда-нибудь людям надоест... играть в жмурки.

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

Поздравляю всех в наступающим Новым Годом!

Ответ на »сообщение 4150« (Владимир Лось)
___________________________

Ответ на »сообщение 4147« (info21)
___________________________
Ну что нам, "Молот Ведьм" с полки доставать? - не томите душу, колитесь, раз уж запустили инфу! :о)

http://coraid.com, Winner "Best Storage Solution" LinuxWorld 2005

Из письма Chief Tenchnical Office and founder Brantley W. Coile III Николаю Вальтеровичу:

>.... What a miserable situation to be in!  It's amazing that we are not
>still programming in FORTRAN and COBOL.
>....
>I've done another startup before Coraid.  In 1994 I co-founded a
>company named Network Translation, where I invented stateful packet
>inspection.  We were the first to sell a product that used Network
>Address Translation (NAT), and the first to offer a firewall that was
>neither a packet filter nor a proxy. ....
>....
>Only after we had sold the company to CISCO did I discover your Oberon
>work.  After reading the Software Practice and Experience articles, I
>saw how crude my attempts were.  My code blocks were similar to
>modules, but my interfaces were fixed and inflexible.  Neither did I
>have dynamic loading.  But I was at least pursuing the right
>objectives.  And my original code as single threaded.
>
>And I also then became aware of the Oberon language.
>................... I know Dennis Ritchie and he's a wonderful
>gentleman.  But I'm at my limits with C. I have lived on both sides of
>the great divide that separates those with faith in strongly typed
>languages from those with faith in permissive ones like the original C
>language.  C now has `grown' as much type checking as possible without
>tearing up the language.  Dennis has said to me that the biggest
>omission of C was parameter checking, which he says he should have
>added to the language in the mid-seventies.
>
>I wrote a good deal of Pascal in the early 1980's and it was the first
>langauge that I felt I knew completley.  The value of strong typing
>was clear, but the illusionary appeal of permissiveness was strong.
>
>Now that I've writting what seems like millions of lines of C over the
>last 20+ years I see the habits I've developed in the design of the
>data structures and code are really just type checking I've added by
>hand.  They are things like checking that pointers fall within the
>memory space alloced for a free list of memory objects, making sure
>free'ed objects have nil next pointers (indicating that they are not
>already on a list somewhere), and putting subscript checking as a
>separate parameter to functions and explicitly checking ranges.  All
>this means that I have to design and rewrite all the type checking for
>every application.  Which is obviously error prone and inefficient.
>
>So, I'm switching to the Oberon programming language.  After
>considering everything, the decision seems easy.  We will be able to
>control the compiler.  Training won't a problem with a language
>described in only 16 pages, and because of your wonderful prose.
>Performance isn't a problem, especially when we can make application
>specific adjustments to the language as you did with the helicopter
>project.  Clearly if you can run a model helicopter, we can make fast
>storge devices with Oberon.
>
>I'm in the process of converting your V4 compiler ..............
>
>........................ Both practitioners of programming and
>the Universities must change to make a difference.  It's sometimes a
>slow and painful process, but like an undervalued stock, Oberon will
>rise to its true value, and will be widely used.
>................................................................
--------------------
Всех с Новым Годом!