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


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

Мне кажется, объектно-ориентированное программирование основано на пересылке сообщений, а не на наследовании.
То есть главное -- полиморфизм, а не наследование.
Наследование -- один из способов обеспечить полиморфизм.
Но (если я не ошибаюсь) существуют объектно-ориентированные языки, где наследования нет, а вместо него используется делегирование. Я имею в виду язык Self.

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

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

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

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

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

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

Один из подходов. Что ж, хорошо. Более того, мне кажется, эта позиция близка Сергею Губанову.

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

Вы идёте от "структурного наполнения" типа, а надо - от функциональности, которой обладает (предоставляет наружу) данный тип.

Тип не обладает функциональностью (классы не рассматриваем).

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

Вот программа на языке Mathematica:
f[x_] := x;

Я утверждаю, что x - это переменная, а f[] - функция. И вряд-ли кто-либо с этим не согласится. Что позволяет мне утверждать, что x - это переменная? Что-то позволяет, но типы тут не причём. То есть понятие переменной, вообще говоря, не связано с понятием тип.
Утверждать, что x -- переменная Вам позволяет тот факт, что x может менять значение в течение времени своего существования. Естественно, типы здесь ни при чём. Но это и никак  не доказывает, что переменная x не имеет типа. Из описания следует, что x может относиться к любому типу (т.е. x может быть любым объектом). И принадлежность x к какому-либо типу (роду объектов) определяется динамически во время выполнения программы.

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

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

Может ли быть удобно и не удобно одновременно? Можно ли одновременно иметь специальное предназначение и не иметь его? Можно ли одновременно быть оптимизированным и не быть им?
В том то и дело, что нет! Я пытаюсь поймать Вас на противоречии: по Вашим словам Oberon НЕ ЯВЛЯЕТСЯ языком, ЗАТОЧЕННЫМ под написание программ для МОДУЛЬНОЙ СИСТЕМЫ WINDOWS, т.е.  НЕ ЯВЛЯЕТСЯ МОДУЛЬНЫМ; с другой стороны Oberon ЗАТОЧЕН под написание программ, для МОДУЛЬНОЙ СИСТЕМЫ OBERON, т.е. ЯВЛЯЕТСЯ МОДУЛЬНЫМ. Таким образом, Oberon одновременно заточен и не заточен, модульный и не модульный, в чём и заключается противоречие.

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

Да, но если мне НЕ нужно, что бы объект принадлежал к какому-либо классу, имеющему функциональность "летать" и тем не менее он мог делать это?

Вы, видимо, не поняли, о чём идёт речь. "Иметь функциональность" <=> "уметь делать". Если Вы имели в виду, что Вам нужно, чтобы разнородные объекты предоставляли требуемую функциональность, то интерфейсы как раз тут Вам и помогут.

Вам даже классы с наследованием часто не понадобятся для построения ОО-систем, представьте такую ересь! :о))))

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

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

Ответ на »сообщение 4089« (info21)
___________________________
Замена колес, конечно, не совсем удачный пример в плане изменения функциональности. Но можно уточнить.
Автомобиль = ядро QNX + то, что загружено вместе со своим state.
Перегружать оное = "обдефолтить" этот самый state, т.е. остановить автомобиль.
Я понимаю ваши затруднения.

Честно говоря, у меня только одно сейчас здесь затруднение: не понимаю, что Вы сказали и как это относится к тому, что сказал я :-)

Пардон, O.Nick опередил... стираю.

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

Ответ на »сообщение 4092« (info21)
___________________________
>> Банальная необходимость -- твердая опора среди... идей.
Наверное, все же... не опора, а стартовая точка, то что заставляет задуматься...
Для старта нужна... опора.
И не только для... старта...
Для старта нужен импульс. Стартовать, по большому счету, можно и из состояния невесомости. Ну, да, не суть...

Суть в том, чтобы в желательное место прилететь, а не... куда попало.
Поэтому все равно в полете нужно ориентироваться -- пусть не материальная, а все равно... опора.