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

...мне иногда приходится вести разговор на грани...
Оно и видно.

Дабы ни у кого не появилось соблазна поверить, но зато появилось желание опровергнуть или доказать (а значит, как минимум, задуматься).
Интересная методика.

Нет, мне тоже верить не следует. Когда Вам откроется нечто, Вы сами поверите, и сомнение никогда не появится. Но к этому надо быть готовым...

УАУ!!! Да у Вас, наверное, и ритуал целый существует посвящения в свою веру?!

... а в зеркале... не встречали? :)
А без шуток?! Это ль не Вы говорили:
Есть праздники и есть будни. Есть работа и есть развлечение. То что уместно (забавно и весело) в одном случае, неуместно в другом... Красить мир одной краской - надо ли...

Основу любого («бесконечного») разнообразия составляет... очень небольшое количество элементов. Разберите «калейдоскоп»... и убедитесь.
Ух ты! А с каких это пор калейдоскоп по сложности приравнен к Homo Sapiens?

«ВСЮ функциональность»... Забавно... А если изменятся условия задачи или появятся другие задачи?
А на что мне наследование и полиморфизм?

Вы, наверное, говорите о простых программах, а я о больших системах.
Ах, да... Я и забыл, что Вы у нас Гуру Больших Систем. А мы то непосвящённые только и можем лепить программки в Delph'ях типа "сложить два числа".

Нам трудно будет понять друг друга.
Уже имел возможность убедиться.

Вы можете «уничтожить Печкина», а я нет (у меня он просто меняет роль).
Нет, у Вас он меняет не роль, а генетический код: был Печкин -- стал Голубь. Круто.

Вы можете переписать программу (выбросив старую реализацию), а я не могу выбросить систему (в ней огромные объемы информации заказчиков).
Мне не обязательно выкидывать программу, чтобы уничтожить (или отправить на пенсию -- как Вам больше нравится) экземпляр Печкин класса Почтальон.

Выбросил/уничтожил и нет проблемы!..
Прям по Сталину... У Вас там случайно не авторитарная секта Верующих в Большие Системы?

Если «переменная» «Пол» класса «Homo Sapiens» может принимать только одно значение из нескольких допустимых, то как же можно... Видимо, я чего-то не понимаю...

Видимо, так... Ведь из Ваших слов пол -- не просто одно из нескольких допустимых значений, это Роль (хотя бы потому, что с полом сопряжены некоторые функции человека как-то: Быть Матерью, Быть Отцом и пр., причём взаимоисключающие друг друга). И всё это у Вас прописано в одном классе, безосновательность чего я и продемонстрировал на примере.

Начните с простых примеров, если хотите, то могу помочь...

Да нет, спасибо, -- я Вам не верю.

А теперь несколько комментариев касательно формы и содержания моего сообщения. Поскольку Вы не представили сколько-нибудь весомой критики моих слов, я решил ответить Вам в схожем духе. И хочу предупредить Вас, что на следующее столь же бессодержательное сообщение отвечать не намерен, поэтому, если вдруг захочется объяснить в двух словах, какой Вы мастер создания Больших Систем, можете не утруждать себя набиванием текста на клавиатуре либо... ...либо избрать жанр монолога.

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

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

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

Вы упорно не желаете видеть. По ВАШИМ словам OBERON одновременно ПРЕДНАЗНАЧЕН И НЕ ПРЕДНАЗНАЧЕН ДЛЯ одного и того же -- МОДУЛЬНЫХ СИСТЕМ, к коим Вы относите и Oberon и Windows.

О чём я и говорил. Но Вы стали спорить...
Ну... Это не красиво. Так вырывать фразы из контекста и манипулировать ими... Я говорил о том, что вы можете утверждать, что x -- переменная, не беря понятие типа в голову. Но это не означает, что в подобных языках нет типов.

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

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

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

Знаете, вообще-то есть несогласные с Вашим видением проблемы. Так что Вы, кажется, поспешили с объявлением консенсуса.

Наследование, иерархия. Широко применяющийся, массовый, но скучный и малопродуктивный механизм.
Согласен здесь с ASU: наследование -- отличный механизм, очень продуктивный.

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

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

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

В сообщении »сообщение 4109« hugi усомнился в том, что (абстрактный) тип данных связан именно с функциональностью.

Насколько я понимаю концепцию АТД, тип данных определяет именно данные, а не функциональность. Функциональность определяется производимыми над переменными этого типа операциями.


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

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

Да? А каким образом вы будете "удовлетворять компилятор" на предмет принадлежности конкретного класса к классу (интерфейсу) "Умеющих Летать"? :о)

Примерно таким, каким Вы в Лимбо.

А вот теперь скажите, эта "отдельная сущность" как-то выражается конкретно в языках программирования? Ведь мы вроде бы все согласны, что языки – это ещё и средство закрепления проектных решений. - А скажите, как вы будете реализовывать требование поддержки классом того или иного интерфейса (реализовывать эти самые напроектированные "решения")?
Выражается. Interface называется. Легко: Класс реализует Интерфейс.

На счёт "не имеют ничего общего с множественным наследованием" и "при их использовании не возникает никаких сколько-нибудь серьёзных противоречий" - это вы погорячились, уважаемый hugi. Вы в книжный магазин заходили? Видели там сколько макулатуры по ОО-проектированию с использование конкретных языков лежит?
Вот не видел я такой макулатуры.
Вот поверьте -- не возникает. Приведу пример из Delphi. Конфликт имен методов реализуемых Интерфейсов разрешается явным указанием принадлежности метода к определённому Интерфейсу.

Помилуйте, смысл – кардинально изменился. Это всё равно, как "вам шашечки нужны или в аэропорт?" Оформление "интерфейсов" в обязательном виде в программе в виде отдельных синтаксических элементов – это обязательное наличие "шашечек". А вот описание конкретных требований в конкретном месте – как раз минимальное требование на возможность "ехать". И будь это телега, частник на копейке или, собственно, такси – вы можете по"ехать" и успеть на самолёт. :о)
Выражайтесь, пожалуйста, яснее.

Наложение будет "1-в-1"? И де тут гибкость?
А вот и ошибаетесь! Здесь отношение "многие ко многим".

УмеющийЛетать описывает некоторую функциональность позволяющую причислить АНАЛИЗИРУЕМЫЙ объект именно к этому классу. Так?
Опять не так. Как раз наоборот, можно причислить класс к набору классов, реализующих конкретный Интерфейс, причём это в классе явно прописывается.

Так и в Лимбо – мы МОЖЕМ думать, что данный объект МОЖЕТ БЫТЬ ПРИЧИСЛЕН к определённому классу, потому, что он имеет какую-либо функциональность (или их совокупность), но классов, как таковых в языке НЕТ.
Возможно, такой подход несколько более гибкий... с сопутствующими обстоятельствами.

...пример из Лимбо может быть переписан и так:
Вот спасибо! Теперь я почти уверен, что всё понял.

не имея не только наследования, но даже "классов" (в ставшем  привычным понимании) вообще...
Ну, если там нет зарезервированного слова class, это не значит, что там нет классов.

Важна конкретика функциональности, а не принадлежность объекта к какому-то там типу (классу)...
А вот конкретика функциональности по большому счёту определяется именно принадлежностью к классу. Или интерфейсу, что более гибко. Или, как в Лимбо, что, может быть, ещё более гибко.

...ООП сделало слишком быстрый переход "в обобщение"...
Это как?

И вообще, изучив Ваши примеры на Лимбо, я задался вопросом: "Проблем с несоответствием имён не возникает, а с неоднозначным соответствием заявленной сигнатуре (когда более одного метода удовлетворяют предъявляемым требованиям)?"

И ещё... При использовании Интерфейсов, которые, как я уже упоминал, выступают в качестве контракта между Вами и используемым Вами классом, у Вас есть практически 100% уверенность, что используемый класс делает то, что Вам нужно, что хорошо в плане безопасности (устойчивости). А как с этим в Лимбо? Если сигнатуре метода сравнения удовлетворяет метод сложения, или сигнатуре метода сложения удовлетворяет метод умножения?

Ответ на »сообщение 4192« (hugi)
___________________________
если авторитетам доверять нельзя, почему Вам можно?
Хм... Как Вы думаете, почему мне иногда приходится вести разговор на грани... Дабы ни у кого не появилось соблазна поверить, но зато появилось желание опровергнуть или доказать (а значит, как минимум, задуматься). Нет, мне тоже верить не следует. Когда Вам откроется нечто, Вы сами поверите, и сомнение никогда не появится. Но к этому надо быть готовым...

А вот я хотел бы посмотреть на Ваш класс Homo Sapiens. :)
... а в зеркале... не встречали? :)
Это сколько же там методов, если он реализует всю возможную функциональность (берусь утверждать, что оно -> Infinite)
Основу любого («бесконечного») разнообразия составляет... очень небольшое количество элементов. Разберите «калейдоскоп»... и убедитесь.
Факт в том, что невозможно предусмотреть ВСЁ, ВСЮ функциональность! Да это и не нужно! Нужно только, чтобы функциональность отвечала требованиям задачи
«ВСЮ функциональность»... Забавно... А если изменятся условия задачи или появятся другие задачи? Вы, наверное, говорите о простых программах, а я о больших системах. Нам трудно будет понять друг друга.

Ну если Вы ВМЕСТО собрались использовать, то тогда просто уничтожаем Печкина и создаём почтового голубя. Здесь Интерфейсы Вам помогут вполне.
Это характерный признак того, что мы говорим о разном. Вы можете «уничтожить Печкина», а я нет (у меня он просто меняет роль). Вы можете переписать программу (выбросив старую реализацию), а я не могу выбросить систему (в ней огромные объемы информации заказчиков). Зачем Вам думать о модификациях? Выбросил/уничтожил и нет проблемы!.. Увы, я так не могу, и потому вынужден вникать в суть.

О! А Вы учли взаимоисключающие роли? Ведь человек может быть мужчиной и женщиной, братом и сестрой... И вся эта функциональность прописана в одном классе! Это явление вообще-то гермафродитизмом называется
Хм... Вы так думаете... Странно... Если «переменная» «Пол» класса «Homo Sapiens» может принимать только одно значение из нескольких допустимых, то как же можно... Видимо, я чего-то не понимаю...

Ваш подход имеет место быть, но не везде и не всегда, а только когда возможно выделение у сущностей очень ограниченного набора низкоуровневых действий, через который посредством комбинации возможно представление всей возможной функциональности. Да и то не всегда, наверное... В случае с Homo Sapiens сделать подобное невозможно
«Дорога в тысячу километров, начинается с первого шага» (Лао-Цзы). Начните с простых примеров, если хотите, то могу помочь...

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

Ах, да. Если кратко: в «статически типизированных» языках тип - синтаксическая категория, а в «динамически типизированных» языках тип – внеязыковое понятие

Ну, если мне не изменяет память, я утверждал, что в динамически-типизированных языках тип есть, а Вы, что его там нет. Но с этим Вашим определением я ПОЧТИ согласен. Единственная поправка -- "в динамически-типизированных языках тип -- внутриязыковое понятие, не имеющее синтаксического отражения".

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

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

Хм... Возможно Вы пропустили, но я говорил о семантике. Исходя из Вашего утверждения у каждого должна быть собственная таблица «Менделеева», собственные буквы и ноты... Наверное, это было бы забавно... Вы возьметесь отрицать возможность существования объективного?

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

Есть понятие классификации, есть понятие иерархии, наконец, есть понятие «наследования» (имеется ввиду наследование в трактовке ООП). Все это суть разные понятия. На самом деле, можно классифицировать камешки на берегу по размеру, по форме, по цвету и даже... по хим. составу. И, очевидно, подобных классификаций «на потребу» можно выдумать очень много.
А я о чём? Именно о классификации.

Например, иерархии «вложения», «подчинения» не являются классификацией.
Разумеется. Иерархия не является классификацией. Даже примеров не надо приводить. Это разные понятия, пусть и связанные.

А, следовательно, говорить о произвольном формировании иерархической классификации при наследовании в ООП – моветон...
Вряд ли можно для одной классификации построить несколько иерархий (хотя, для одной и той же классификации можно строить иерархии вложения, наследования и пр., но две иерархии вложения построить -- проблематично, на мой взгляд). НО, разные классификации -- разные иерархии. Вот и всё...

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

Хм... Мне кажется, что Буч заслуживает аплодисментов! Такое искусное жульничание на основе подмены понятий должно достойно вознаграждаться. :)
Может, объясните для тех, кто в танке, где у него подмена понятий?

Хм... Хотя почему бы и нет?.. Если уж так хочется...
А вот это уже граничит с оскорблением. Если в ответ на сообщение Сергея Губанова  я пытался отшутиться, то здесь мне уже не до шуток.

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

Модель либо отражает смысл, либо нет...
Модель не может отражать ВЕСЬ смысл.
Еще как может! (А что такое, скажем... половина смысла?) Вы же не смогли найти ущербности в модели склада... :)
Смысл ведь тоже субъективное понятие
О, нет! Пусть любой из тех, кто присутствует, предложит свой вариант модели склада... Обсудим. Смысл, не может быть субъективным, он задается извне, из надсистемы (специально отмечу, что даже «создатель» не всегда понимает смысл своего творения...).
Для многих в наших разговорах вообще никакого смысла. А для нас есть, причем разный
Хм... Для того, кто закрыл глаза, света тоже нет, но это еще не означает, что света не существует. В нашем разговоре есть смысл... надо только его понять (я говорил, что понимание смысла занятие не самое простое, но самое полезное...).

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

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

боюсь, что это могут расценить, как рекламу
Не надо бояться, скорее расценят как повод для обсуждения, что на базарной площади поощряется
Хорошо, но надо создать новую тему, поскольку это к «мыслям об Обероне» это отношения не имеет... или вернуться к «лженауке» :)

Творческих успехов всем в Новом Году!

Вновь приветствую участников дискуссии, поздравляю всех с Новым Годом и приношу извинения за длительное отсутствие, но... дела, дела, дела...

Итак, приступим...

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

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

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

Что Вы понимаете под функциональностью Homo Sapiens ... и т.д ... и т.п.
А вот я хотел бы посмотреть на Ваш класс Homo Sapiens. :) Это сколько же там методов, если он реализует всю возможную функциональность (берусь утверждать, что оно -> Infinite). И Ваше замечание про бесконечное число ипостасей вступает в противоречие с Вашим же подходом. Факт в том, что невозможно предусмотреть ВСЁ, ВСЮ функциональность! Да это и не нужно! Нужно только, чтобы функциональность отвечала требованиям задачи.

...Вашим кумирам...
Маленькая просьба -- не приписывайте мне своих домыслов. Держите их при себе.

Наш Почтальон бросил работу на почте и стал Садовником. Что делать-то будем? «Отрезать» одну функциональность и наращивать новую? На всякий случай замечу, что объект почтальон-Печкин (экземпляр класса «Почтальон») у нас уже реально существует. Значит теперь мы будем вынуждены сменить класс у объекта?

Здесь разные варианты возможны. Вполне подойдёт вариант, предложенный Сергеем Губановым.

Вместо почтальона-Печкина на почте стали использовать «почтовых» голубей. Срочно заставляем Печкина скрещиваться с голубкой?
Ну если Вы ВМЕСТО собрались использовать, то тогда просто уничтожаем Печкина и создаём почтового голубя. Здесь Интерфейсы Вам помогут вполне.

Или по совету «мудрого» Буча выносим «функциональность» «быть почтальоном» в отдельный класс и начинаем «прививать» его по мере необходимости разной живности и представителям Homo Sapiens?
"Прививка" -- всего навсего технологическое решение, используемое в C++. Мне оно тоже не очень нравится.

Только профессии – это еще цветочки. Человек (то бишь, Homo Sapiens) может еще быть внуком, сыном, мужем, отцом, дедом, внучкой, дочкой, женой, матерью, бабушкой, дядей, тетей, племянником и племянницей и т.д. и т.п., продолжаем: другом, недругом, помощником и саботажником, и т.д. и т.п.
О! А Вы учли взаимоисключающие роли? Ведь человек может быть мужчиной и женщиной, братом и сестрой... И вся эта функциональность прописана в одном классе! Это явление вообще-то гермафродитизмом называется.

Честное слово, меньше всего мне бы хотелось увидеть то, что у Вас получится в результате...
А мне бы на Вашего Homo Sapiens очень хотелось взглянуть... :)

«Не сотвори себе кумира»
Кто бы спорил...

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