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

=Смысл объективен, субъективно восприятие и выражение смысла
вот-вот, восприятие смысла субъективно. поэтому не "смысл не может быть общим", а "восприятие смысла не может быть общим"
==Нет, не ощущаю... Если каждый воспринимает свое, то как же можно договориться об общности восприятия.

превосходно! я: "восприятие смысла не может быть общим". вы [выражая несогласие]: "Если каждый воспринимает свое, то как же можно договориться об общности восприятия".

потому и не могут, что... - далее см. еще раз мое утверждение. ваша логика не только полна противоречий, но еще и насквозь пропитана непониманием того, о чем пишет ваш оппонент.

Конечно, нет. Смысл не имеет ни размеров, ни уровней, ни сторон.

я говорил, что смысл - эфемерная категория. но вы с этим категорически несогласились.

=жан-жак руссо писал: "заблуждаются не потому, что не знают, а потому, что думают, что знают"
==Жан-Жак Руссо – прав, поскольку говорит о знаниях. Знания к смыслу... «никаким боком».

между словом "знать" и словом "думать" - громадная пропасть. руссо говорил совсем не о знаниях. за указующим перстом вы не увидели луны.

Ответ на »сообщение 4298« (sdf)
___________________________
Смысл объективен, субъективно восприятие и выражение смысла
вот-вот, восприятие смысла субъективно. поэтому не "смысл не может быть общим", а "восприятие смысла не может быть общим"
Нет, не ощущаю... Если каждый воспринимает свое, то как же можно договориться об общности восприятия. Люди пользуются представлениями (о смысле, в том числе) и договариваются о представлениях. Общность представлений, понятий, определений – это совершенно нормально, но общность смысла – нет. Можно придти к соглашению, что вот это явление будем называть так-то и так-то и определять его, так-то и так-то. Возможно потом данное определение претерпит изменения – и это нормально, но смысл не изменится... он либо понимаем кем-то, либо – нет.
разницу ощущаете? и не верно "нельзя передать смысл", а скорее "трудно передать восприятие смысла"
Восприятие передать, как правило, нетрудно, поскольку «истина всегда проста». Но восприятие смысла и смысл – это совсем разные вещи...

Слова имеют (свой!) смысл... Словами можно подвести к пониманию смысла предмета/сущности/действия/...
т.е. есть смысл, а есть смысл. маленький смысл и большой смысл. смысл низкоуровневый (для слов) и смысл высокоуровневый (для индивидуумов). смысл встроенный и смысл внешний
Конечно, нет. Смысл не имеет ни размеров, ни уровней, ни сторон.

Ну, примерно этого... стоило ожидать... «Виноград зелен, объявила лиса, не сумев его достать» (Эзоп).

жан-жак руссо писал: "заблуждаются не потому, что не знают, а потому, что думают, что знают"
Жан-Жак Руссо – прав, поскольку говорит о знаниях. Знания к смыслу... «никаким боком».

Ответ на »сообщение 4292« (Горбунов-Посадов)
___________________________
Ваша "объектная фабрика", "база данных проекта", как мне кажется, -- действительно перспективные направления развития программистского инструментария. С помощью подобных средств неплохо решается заметная часть задач компонентного программирования, не охваченных ООП. Но меня волнует именно "общепринятость" этих средств, к которой Вы почему-то так прохладно отнеслись. Хочется попытаться вычленить среди находок, бытующих в среде разработчиков инструментария, какой-то новый "инвариант" (если хотите, аналог Вашего склада-демпфера), т.е. достаточно четко очерченное компактное понятие, существенно дополняющее установившиеся сейчас каноны и даже, возможно, позволяющее впоследствии в некотором смысле говорить о полноте сложившегося набора инструментов программиста
Хм... Если интересует концептуальный уровень, то его можно обсудить, если же инструментальный, то, увы...

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

Смысл объективен, субъективно восприятие и выражение смысла.

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

Слова имеют (свой!) смысл... Словами можно подвести к пониманию смысла предмета/сущности/действия/...

т.е. есть смысл, а есть смысл. маленький смысл и большой смысл. смысл низкоуровневый (для слов) и смысл высокоуровневый (для индивидуумов). смысл встроенный и смысл внешний.

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

Ну, примерно этого... стоило ожидать... «Виноград зелен, объявила лиса, не сумев его достать» (Эзоп).

жан-жак руссо писал: "заблуждаются не потому, что не знают, а потому, что думают, что знают."

Ответ на »сообщение 4290« (hugi)
___________________________
Не давал я таких сведений... да, и... Homo такой же мой, как и Ваш... :)
Отказываться от своих слов нехорошо. Вы же говорили, что будете в классе HomoSapiens прописывать все элементарные операции, через которые возможно выразить все возможные роли человека? Говорили. Из чего напрашивается естественный вывод -- класс у Вас один, возможностей он предоставляет много. Я с этих позиций пытался рассматривать Ваш подход к проектированию систем
Да, с чего Вы взяли, что я отказываюсь от своих слов? Вы пишите (4288): «Тогда, могу предположить, используя сведения о Вашем подходе, описанном в сообщениях, адресованных мне, что вся ваша система описана в одном классе, который является "агрегатом ролей" (это по аналогии с Вашим HomoSapiens). Но мне почему-то кажется, что Вы, вопреки своим рассуждениям, сделали иначе». Покажите мне то сообщение, где говорится о системе в одном классе, который является «агрегатом ролей», я таких сведений Вам не давал... пока.
Что Вы понимаете под «агрегатом ролей»? Я говорил о том, что роль агрегирует интерфейсы. Разницу понимаете? Да, какой-то объект может выступать в разных ролях, но сие не означает, что он агрегирует роли! Сам объект про роли, которые он исполняет, может ничего не знать. Роль – это поименованная совокупность интерфейсов, но роль – это не класс и не объект.
Что же касается «системы в одном классе»... Несколько раз в разговоре с Вами я говорил о композиции (см. например, 4204): «Хм... сколько степеней свободы имеет палец? А рука? А все тело человека? Продолжать или уже понятно?.. Сколько музыкальных произведений существует? Много?! А нот всего семь... а параметра только три... Сколько действий может совершить человек? Много?! А если разложить на простые движения (которых всего-то два: поступательное и вращательное)... «Зачем делать сложным то, что проще простого?». Характеристики (свойства) – это проявления (вовне) композиций из очень малого количества исходных (внутренних) элементов. Можно перечислять композиции, а можно попробовать понять их основу и правила построения (создания)». Но Вы упорно игнорируете возможность комбинирования, считая, что таких «сложных» системах, как Человек, нужно «прописывать все элементарные операции»... по всей видимости предполагая, что этих элементарных операций очень много. Много комбинаций, но не операций.

Нет... ничего нет про наследование, Вы правы... Но открываем раздел «Наследование и типизация»:
И что? Про "искусную подмену понятий" уже забыли, мои слова по этому поводу и пример Буча опровергнуть нечем, вот и начинаете искать страницы, на которых у него про наследование говорится...
Почему Вы решили, что пример Буча нечем опровергнуть? Давайте разбираться... Предположим, что у нас описан некий класс, который имеет характеристики (пусть для примера характеристик будет три и они будут целочисленные). Теперь создадим несколько экземпляров данного класса (то есть, объектов) и присвоим характеристикам некие значения. Что мы получили? Полигон для тренировок по произвольной классификации. Например, можно классифицировать объекты по следующим параметрам: те, у кого первая характеристика меньше 1000, и те, у которых данная характеристика больше или равна 1000. Или так: те, у кого (характеристика1 + характеристика2) div характеристика3 < 1000 и... прочие. Сколько подобных классификаций можно предложить? Бесконечно много. Согласны? Но! Мы можем так «классифицировать» объекты некоего ранее созданного класса. Если бы не было ранее созданного класса, то и объектов бы не было, а, следовательно, и не на чем было бы упражняться. Правильно? Давайте подведем первую черту. Мы практиковались в классификации, рассматривая значения характеристик у объектов заданного класса. Подобные «классификации» удобны для решения каких-то практических задач, но они... бесполезны для целей получения иерархии наследования. В свою очередь, иерархия наследования – это тоже классификация, но принципиально иная, и понятие «класса» в ООП определяется именно иерархией наследования, но не той произвольной «классификацией». Замените понятие произвольной «классификации» на группировку по тем или иным признакам и... ничего не изменится в понятийном аппарате. Но нельзя столь же легко заменить понятие «класса» в ООП на произвольную «группу», поскольку класс определяет «родовые признаки», тот самый набор характеристик... не значения характеристик, но сами характеристики.
Но вот мы и подошли к «подмене понятий»... Давайте вспомним сообщение (4073), в котором я говорил: «В основе ООП не лежит решение частных задач, важнее получить семантически стройную иерархию классов. Об этом забыли... иерархии начали строить на потребу... Потому сегодня проводить межи и расставлять разделительные вешки между модульным программированием и ООП... пустая трата времени, IMHO. Но разговор о семантическом моделировании и принципах построения хороших классификаций... совсем другая тема.». Отметьте, что у меня речь, шла о наследовании, о построении иерархии классов. А вот Ваша реплика (4074): «Видимо Буча, так Вас рассмешившего, всё-таки невнимательно читали. Он  в своём "ОО Проектировании" наглядно показывает, что "хороших" классификаций не бывает»... Здесь Вы уже говорите не о классификации наследования, а о... классификации-группировке... С этого все и началось... Так кто же подменил понятия: я или Вы?

кстати оно [наследование] там не только на 126 странице упоминается
О! Да!.. О наследовании Буч говорит много... слишком много... и смешно... Чтобы меня не обвиняли в голословности, приведу несколько цитат (все равно книгу уже нашел...).
Раздел 1.2. (стр. 33) «структура растений и животных»
Растение состоит из трех основных частей: корни, стебли и листья.
Раздел 2.2. (стр. 74-75) «примеры иерархии: множественное наследование»
Изучая предметную область, мы приходим к выводу, что различные группы культивируемых растений – цветы, фрукты и овощи, - имеют свои особые свойства, существенные для технологии их выращивания. Например, для цветов важно знать времена цветения и созревания семян. Аналогично, время сбора урожая важно для абстракций фруктов и овощей. Создадим два новых класса – цветы (Flower) и фрукты-овощи (FruitVegetable); оба они наследуют от класса Plant. Однако некоторые цветочные растения имеют плоды! Для этой абстракции придется создавать третий класс, FlowerFruitVegetable, который будет наследовать от классов Flower и FruitVegetablePlant.
Чтобы не было избыточности, в данном случае очень пригодится множественное наследование. ...
Мы намерено описали эти два класса [FlowerMixin и FruitVegetableMixin] без наследования. Они ни от кого не наследуют и специально предназначены для того, чтобы их подмешивали (откуда и имя Mixin) к другим классам
Что же получается... Если дерево состоит из частей, то почему растение, например, яблоня – есть яблоко? Почему в одном случае растение имеет корни, то в другом случае растение происходит от цветов, а не имеет цветы? И что такое цветок, который не растение и не часть его? И что произойдет с проектом, если «подмешивающих» (неприкаянных) классов будет очень много?..
Но апофеозом является следующая фраза: «Часто агрегацию путают с множественным наследованием. Действительно, в С++ скрытое (защищенное или закрытое) наследование почти всегда можно заменить скрытой агрегацией экземпляра суперкласса. Решая, с чем вы имеете дело – с наследованием или агрегацией – будьте осторожны. Если вы не уверены, что налицо отношение общего и частого (is a), вместо вместо наследования лучше применять агрегацию или что-нибудь еще.» (стр. 133 Глава 3. Агрегация.)
Все... финал, Буч честно признался, что он не в состоянии привести критерии для того, чтобы разделить понятия наследования и агрегации. ... смешно и грустно... одновременно... Правда, таких перлов в книге более, чем... Посмотрите его описания «сложных систем», описания ключевых понятий ООП, подходы к разработке и организации работы команды...

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

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

Ответ на »сообщение 4282« (info21)
Но Stores, как и Views -- не компоненты.
+ Controllers и т.п.
Так вот и жаль, что не компоненты. Могли бы быть компонентами...

Почему жаль? Трудно считать их компонентами. Компонента (по кр. мере в трактовке Шиперского) -- вещь конкретная. Тот же Text дает конкретную весчь, хоть и спрятанную под ABSTRACT интерфейсами.

Но мой предыдущий пост -- частичное согласие, что жаль.

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

Ответ на »сообщение 4267« (info21)
___________________________
Наследование (в ООП) – всегда классификация ...
Конкретно в Блэкбоксе: дан базовый тип View. От него производятся разные, никак между собой не связанные конкретные вьюшки.
Никакого отношения к классификации это не имеет, если не считать классификацией любое определение ..

В Вашем примере, если от базового типа View наследованы вьюшки, то зачем-то это было сделано...

Чтобы выделить вьюшки среди... не-вьюшек.

В сущности, это не более чем одно определение: вьюшка = нечто, у чего есть функциональность, описанная во View. Определение -- вырожденный случай классификации, но об этом случае говорить как о классификации неинтересно и misleading.

Мой тезис в том, что механизм расширения типов+полиморфизм определенно примитивнее и потому общЕе, чем средство классификации.

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

---------------------------
Кстати вопрос: если ограничить наследование одним звеном предок/потомок: Потеряется ли что-нибудь принципиальное в плане возможности "отслаивать" функциональность?
Например, Stores/Views кажется достаточно легко построить и с однократным наследованием: финальный тип ViewStores, который уже композицией связан с View, а View бы подсовывал куда надо этот ViewStores, когда надо прикинуться Store'ом.

Возможно, это решило бы затруднения С.Губанова со Stores. (У меня, впрочем, тоже здесь ощущение легкого дискомфорта, хотя и не такое драматичное.)

Сей механизм "делегатов" был бы достаточен и для моделирования множественного наследования в Оберонах. Если он достаточен там, то должен быть достаточен здесь, и наоборот.

Есть ли контпример? (Обычно наш Trurl быстр в таких задачках.)

Ответ на »сообщение 4282« (info21)
Но Stores, как и Views -- не компоненты.

+ Controllers и т.п.

Так вот и жаль, что не компоненты. Могли бы быть компонентами...

Ответ на »сообщение 4282« (info21)
___________________________
А ведь Сергей Губанов прав, фабриками вопрос не решается:

MODULE TestM1;

TYPE
T* = POINTER TO ABSTRACT RECORD
(*  private: INTEGER  *)
END;
TIm = POINTER TO RECORD ( T ) END;
Directory* = POINTER TO ABSTRACT RECORD END;
StdDirectory = POINTER TO RECORD (Directory) END;

VAR
dir-, stdDir-: Directory;

PROCEDURE (d: Directory) New* (): T, NEW, ABSTRACT;

PROCEDURE SetDir* (dir: Directory);
BEGIN
stdDir := dir
END SetDir;


PROCEDURE (d: StdDirectory) New* (): T;
VAR t: TIm;
BEGIN
NEW( t ); RETURN t
END New;



PROCEDURE Init;
VAR d: StdDirectory;
BEGIN
NEW( d ); dir := d; stdDir := d
END Init;

BEGIN
Init
END TestM1.
___________________________
MODULE TestM2;

IMPORT TestM1, log := StdLog;

TYPE
T = POINTER TO RECORD (TestM1.T)
  data: INTEGER
END;

Directory = POINTER TO RECORD (TestM1.Directory) END;

PROCEDURE (d: Directory) New(): TestM1.T;
VAR t: T;
BEGIN
NEW( t ); RETURN t
END New;

 
PROCEDURE Do*;
VAR t: TestM1.T; dir: Directory;
BEGIN
NEW( dir );
TestM1.SetDir(dir);
t := TestM1.stdDir.New();

WITH t: T DO
t.data := 234;
log.Int(t.data); log.Ln
END;
END Do;

END TestM2.
(!) TestM2.Do

Если убрать/поставить комментарий в TestM1.T (* private: INTEGER *) не перекомпилируя второй модуль, то при выполнении TestM2.Do получим:

command error: object TestM1.T^ inconsistently imported from TestM2

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

Возможно, Вы имели в виду, что энергичное использование универсальных механизмов СУБД при подключении к программе нового компонента — вполне обыденное дело для ООП? Это было бы очень неплохо, но не думаю, что такое расширенное толкование ООП общепринято.

Дело не в общепринятости... Есть такое понятие, как «объектная фабрика» (его тоже не стоит причислять к общепринятым понятиям). По сути ОФ должна обслуживать множество программ, создавая/восстанавливая/сохраняя/разделяя для них объекты. При этом могут создаваться новые классы, которые тут же могут использоваться работающими программами. Это похоже на совместную работу пользователей с БД (один завел информацию, другие ее увидели и как-то обработали). Можно найти/увидеть (провести) много параллелей между СУБД и ОФ.

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