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

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

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

Это не ответ. Я потому и задал этот вопрос, что ответ на него покажет различия в подходах уже на стадии проектирования...
Я имел в виду, что синтаксическая конструкция, предназначенная для этого (Класс реализует Интерфейс), не намного сложнее используемой в Limbo.

Не вырывайте фразы из контекста. Вопрос был не в том, что я не знаю, как это делается в отдельных языках...

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

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

Извольте. "Шашечки" – это обязательность выражения средствами языка придуманными вами интерфейсов и классов. Но, как я уже писал выше вы не всегда МОЖЕТЕ это сделать. "Ехать" – обеспечение сущностями (объектами) функциональности. В случае с процедурой сортировки, Вы ОБЯЗАНЫ вводить в описания интерфейсов методов с сигнатурой, затребованной процедурой сортировки. В случае с Лимбо важно просто наличие такого метода в АТД.
Честно сказать, не намного яснее, ну, да ладно. На самом деле в случае с Интерфейсами Вы тоже ОБЯЗАНЫ реализовать в своём классе Интерфейс Сравнимый.

А как на счёт динамики изменения набора в классах, к исходникам которых вы не имеете доступа? Мы ведь и о гибкости проектирования речь вели, так? :о)
А причём здесь отношения "1-в-1" или "многие ко многим"? Непонятно... Ну, да ладно...
Вы имеете в виду набор интерфейсов? Так исходники править не надо. Можно использовать механизм наследования и новый интерфейс реализовывать в подклассе. Если же Вы имеете в виду изменение набора интерфейсов во время выполнения то здесь Вам помогут агрегаты, о которых, кстати, Сергей Губанов говорил.

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

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

И вы будете так же успешно использовать чужие компоненты, как и раньше (при прежнем варианте проекта), не имея доступа к их исходному коду?
Так и нужно, вообще-то...

Кроме того- и скомканный лист бумаги "летает"... :о)
Естественно, если Вы пропишите у него соответствующую функциональность. Понимаете, если при традиционном подходе утверждается, что не имеет значения КАК объект реализует требуемую функциональность, то в данном случае даже не имеет значения КТО её реализует. Это до некоторой степени развязывает руки.

Есть и сопутствующие обстоятельства... Я о них уже упоминал. Я имею в виду желательность (а, скорее, даже – необходимость) введения синтаксиса "в месте вызова" такой полиморфной функции. Может быть ситуация, когда нужная функция в объекте есть (семантика), и сигнатура по аргументам та, что нужно, да вот беда, имя отличается. В этом случае желательно с помощью некоей синтаксической конструкции указать компилятору, что за функцию действительно надо иметь в виду.
А я имел в виду несколько другое... Или Вы проигнорировали мой вопрос: "Проблем с несоответствием имён не возникает, а с неоднозначным соответствием заявленной сигнатуре (когда более одного метода удовлетворяют предъявляемым требованиям)?".

Там есть только АТД. Они так и ввели слово adt (abstract data type). Это нечто, как структура с функциями. Класс без наследования.
Классы вполне могут существовать без наследования (в Объектных языках). А утверждать, что в Limbo именно классы, а не АТД мне позволил тот факт, что там используется механизм посылки сообщений (как в Java, Delphi, C++, C#), а не вызова процедур с передачей переменной абстрактного типа как параметра.

КЛАСС – вторичен. Он – результат нашего анализа, абстрагирования. Предмет не принадлежит какому-то там классу "сам по себе". Классы – только у нас в голове. Природа изначально "деклассирована"... :о)
Кто бы спорил... Однако классификация -- отличный механизм упорядочения и борьбы со сложностью окружающего мира. И классификация осуществляется в большинстве случаев на основе выявления схожих характеристик или функциональности.

Это я на счёт леса наследования и его прямой связи с лесом абстракций, полученных при анализе...
Очень часто первое строится только исходя из достижения максимального повторного использования кода, а не функциональности...
Объясните, пожалуйста, чем повторное использование кода отличается от повторного использования функциональности.

Дык у нас и в "обычных" ООП-языках никакой гарантии по семантике нет. Взять хотя бы знаменитый пример с перегрузкой операций. Обычно главным аргументом против такой широкой практики как раз и служит отсутствие чёткого понимания (из текста программы) что конкретно за операции (смысл) стоят за конкретным значком... Интерфейсы пока не описывают семантики... К сожалению... :о)
Да, нет же! Я не то имел в виду! Я имел в виду, что в Вашем примере можно, насколько я понял, передать в функцию сортировки переменную типа, в котором будет объявлена функция, сигнатура которой совпадает с сигнатурой функции сравнения, но это будет другая функция, однако функция сортировки не будет возмущаться по этому поводу, т.к. сигнатуры совпадают. Это ведёт к снижению уровня безопасности (устойчивости) программы. Как с этим бороться? А в случае с Интерфейсами ИМЯ функции говорит Вам, что эта функция делает. И, как я уже говорил, если Класс реализует Интерфейс Сравнимый, это означает с вероятностью ~100% (если только это не чья-то злая шутка), что в нём заявлена функция, позвляющая сравнивать экземпляры данного класса между собой. А вот что означает сигнатура (Self : ThisType; x : SomeType) : Boolean -- трудно сказать: то ли сравнение, то ли проверку делимости, то ли ещё что нибудь -- не понятно... Ибо имя -- не что иное, как отражение семантики. В этом его ценность.

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

Однако инерция ООП и в этой работе весьма заметна.

Вообще-то нужно отдавать себе отчет, что формулы (КОП = ООП +/-)возникли в контекстах типа "чем отличается КОП от ООП" и изначально предназначались для определенной категории людей.

Кстати, к формулам Шиперского тоже можно придраться: то конкретное "ООП", которое там фигурирует, это тоже некий конкретный род ООП.

Но тут формула попала человеку, едва знакомому с ООП...

Ответ на вопрос "что такое число" будет разным для разных вопрошающих. (Спросите... хоть ASU.)

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

А уважаемому Г.-П. наблюдение: вербальные рассуждения Шиперского в основном соответствуют тому, как устроен Блэкбокса (т.к. весьма молодой на момент написания своего опуса по КОП Шиперский сделал единственный проект -- ББ). Поэтому самое лучшее, что можно сделать, это разобраться с тем, как устроен ББ. (ББ, а не другой Оберон -- т.к. мы обсуждаем формулы Шиперского.)

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

Согласен с Вами с том, что когда число объектов превышает некоторую критическую массу, первое, что приходит в голову, -- а не учредить ли среди них иерархию? Сравнительно короткое время иерархия в самом деле помогает. Для реестра Windows, на мой взгляд, это время давно в прошлом

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

да и сама иерархия может быть совсем не иерархией: напр., файловая система unix вроде бы иерархична, а на самом деле...

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

Только соединяя воедино однородные кванты информации, делегируемые отдельными приложениями, можно получить искомое продуктивное сращивание приложений и ОС.

с этим утверждением трудно спорить. соединять лучше однородные вещи. но я бы внес уточнение: что вообще запрещает стирать границы между операционной системой и приложениями?

кстати, а где в системе оберон заканчивается операционная система и начинаются собственно приложения?

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

Может быть, я напрасно упомянул реестр Windows.

реестр имеет иерархическую структуру.

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

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

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

Смысл не может быть общим, смысл каждый открывает сам.

a) смысл (семантика) не может быть общим (для группы людей) ==> смысл субъективен (не отчуждаем от человека)

b) смысл субъективен ==> обсуждение слов (в этом форуме публикуются слова) означает не поиск общего понимания (компромисса, консенсуса), а "извлечение" смысла каждым конкретно участником ==> с точки зрения нахождения общих подходов к проблемам форум бессмысленный. это просто "интеллектуальный эгоизм".

»сообщение 4254«

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

как же можно объяснить семантику, пояснить смысл, если, как вы говорите, "смысл каждый открывает сам" и "нельзя передать смысл" (»сообщение 4254«)?


Смысл действительно нельзя «извлечь» из человека (в отличие от знаний), но можно понять то, открыт ли смысл данному человеку или нет.

каким образом можно понять, открыт или нет? что есть критерии понимания? открыт ли, например, мне смысл "склада"? кто это может выявить? является ли этот процесс выявления объективным или он все же субъективен?

все это из серии "вот и приехали..."

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

приведу эту замечательную подборку.

  1. Хамите.
  2. Хо-хо! (Выражает, в зависимости от обстоятельств, иронию,  удивле-
ние, восторг, ненависть, радость, презрение и удовлетворенность.)
  3. Знаменито.
  4. Мрачный. (По отношению ко всему. Например: "мрачный Петя  пришел",
"мрачная погода", "мрачный случай", "мрачный кот" и т. д.)
  5. Мрак.
  6. Жуть. (Жуткий. Например, при встрече с  доброй  знакомой:  "жуткая
встреча".)
  7. Парниша. (По отношению ко всем знакомым  мужчинам,  независимо  от
возраста и общественного положения.)
  8. Не учите меня жить.
  9. Как ребенка. ("Я его бью, как ребенка" - при игре в карты. "Я  его
срезала, как ребенка" - как видно, в разговоре с  ответственным  съемщи-
ком.)
  10. Кр-р-расота!
  11. Толстый и красивый. (Употребляется как  характеристика  неодушев-
ленных и одушевленных предметов.)
  12. Поедем на извозчике. (Говорится мужу.)
  13. Поедем в таксо. (Знакомым мужеского* пола.)
  14. У вас вся спина белая (шутка).
  15. Подумаешь!
  16. Уля. (Ласкательное окончание имен. Например: Мишуля, Зинуля.)
  17. Ого! (Ирония, удивление, восторг, ненависть, радость, презрение и
удовлетворенность.)

какая потрясающая мощь семантики! а полиморфизм-то какой! а вы говорите "смысл"...

type
  Склад = class
    Content: variant;
    function ЗатолкатьНечтоВСклад(Нечто:variant; входные_документы:документы):документы;
    function ВытолкатьНечтоСоСклада(отгрузочные_документы:документы):variant;
    //вообщето выпираются еще и некие документы, ну да ладно
    function СообщитьОВнутреннемСостоянии:документы;
  end;

Так нормально? :)
Понимаю, что описательное определение - это не определение, но его вполне достаточно для решения практических задач, не так ли?

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

этот смысл у человека в голове. никто туда не заглянет
Это и правильно и неправильно... одновременно. Смысл действительно нельзя «извлечь» из человека (в отличие от знаний), но можно понять то, открыт ли смысл данному человеку или нет.

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

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

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

Рассматривайте в данном контексте логистику, как управление материальным потоком.

есть система автоматизации работы склада, есть система учета. осуществляется регистрация потоков. но в действительности потоков не было и нет. так они материальны с точки зрения "управления материальным потоком" или нет?

Тогда этот термин утратит смысл...

обратите внимание: утратит для вас (ASU), но не для меня.

То есть, семантика Вашего определения «непрозрачна», а, следовательно, она и не семантика...

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

Хм... Мне кажется, что утвердительный ответ я уже давно дал. С той только разницей, что определения склада я не давал, но провел аналогию с демпфером.

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

Вы смотрите на ячейку камеры хранения глазами потребителя, я же говорю о самой ячейке/камере хранения.

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

Здесь мы не сможем понять друг друга...

откуда такое заключение? возможно вы и не можете (или не хотите) понять. мне представляется, что я хорошо понимаю вас. так что взаимности непонимания тут, на мой взгляд, нет.

Из этих слов следует, что кто-то ошибается/заблуждается (в понятиях, терминах), либо  я, либо «подавляющее большинство людей» во главе с Вами. Пусть лучше это буду я...

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

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

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

В толковых словарях нет смысла, есть объяснения

готов почти согласиться. надо только прояснить одну мелочь: а ваши слова - это объяснения или смысл? и где у вас слова, а где смысл? может быть, это как-то стоит отмечать (например, выделением или цветом)?

Ответ на »сообщение 4249« (sdf)
___________________________
Фиктивный «склад», то есть склада нет, есть только фикция.
с точки зрения традиционной системы автоматизации работы склада, фиктивный склад - реальность. отличить фикцию от реальности для склада система без наличия специальных датчиков, обеспечивающих ввод "объективной" информации, не может. это не всегда может сделать даже следственная группа, не то, что программное обеспечение. склад в чистом виде. причем "соленый" (демпфирующий)
Фиктивный склад вводится, как правило, для «корректировки» учетной информации. Я говорю о сути понятия склада, а не о том, как им... махинируют.

>> 3. Склад на продукцию не пользующуюся спросом. Выгрузки нет.
Хранилище
ага. нефтехранилище, газохранилище, зернохранилище и овощехранилище - это никакие не склады, у них, конечно, нет входных и выходных потоков и они, разумеется, не участвуют в логистике. просто так стоят сами по себе в сторонке
В этом причина нашего непонимания: Вы ориентируетесь на слова, я - на смысл.  «Нефтехранилище, газохранилище, зернохранилище и овощехранилище» - это, как правило, склады. Слова, к сожалению, не всегда передают смысл, а иногда... искажают его до неузнаваемости. Например, в том же словаре Ожегова слово «прелесть» трактуется, как:
1. Очарование, обаяние, привлекательность. П. детской улыбки. П. новизны. В суровости севера есть своя п.
2. мн. Приятные, пленящие явления, впечатления. Прелести сельской жизни. Узнал все прелести подневольной жизни (ирон.: о её тягостях).
3. О ком-чёмн. прелестном, чарующем. Какая п. кругом! Что за п. эта девчонка! П. ты моя!
4. мн. Внешние черты женской красоты: женское тело (устар. и ирон.). Увядающие прелести.
• Прелесть что такое! (разг.) о чёмн. прелестном, замечательном.»
А изначальный смысл этого слова едва ли не противоположный. «Впасть в прелесть», «прельститься», «польститься» и т.д., то, есть, соблазн, искушение, недоброе устремление к чему-то/увлечение чем-то. Прелесть – это то, чем искушают с корыстными [недобрыми] побуждениями.
В другой теме я обсуждал слово «сложный»... «с ложью»... Примеров, когда использование слов не соответствует их смыслу, очень много... к сожалению.