Ответ на »сообщение 4272« (Takun)
А в чем собственно проблема? Другая реализация абстрактного класса (Stores, Views и т.д.) не обязана совпадать с "эталонной" по скрытым полям. Компилятор и загрузчик ориентируются только на экспротируемые поля. По крайней мере в случае указателей на записи, для них изменение размера структуры значения не имеет.

Как в чём проблема? Проблема хотя бы в том, что, например, инструкции NEW() нужно знать размер объекта. Скрытые поля влияют на размер. Новый Stores.Store должен иметь теже самые скрытые поля, что и старый.

MODULE M1;

  TYPE
    T* = POINTER TO ABSTRACT RECORD
      (* private: INTEGER *)
    END;
   
END M1.

MODULE M2;

  IMPORT Log, M1;
 
  TYPE
    T* = POINTER TO RECORD (M1.T)
      data: INTEGER
    END;

  PROCEDURE  NewT (): T;
    VAR t: T;
  BEGIN NEW(t); t.data := 12345; RETURN t
  END NewT;
 
  PROCEDURE Do*;
    VAR t: T;
  BEGIN t := NewT();
    Log.Int(t.data); Log.Ln
  END Do;

END M2.

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

command error: object M1.T^ inconsistently imported from M2

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

Но почему-то он не замечает одного из основных механизмов Windows, отвечающего за инсталляцию, -- реестра (регистра). Механизмы реестра, похоже, не разложимы по базису ООП

Реестр представляет собой «базу данных» и с этой точки зрения вполне «разложим по базису ООП».

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

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

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

Ответ на »сообщение 4274« (sdf)
___________________________
попробуем грешным образом их поанализировать как логические утверждения.
a+b ==> один и тот же смысл не может принадлежать нескольким индивидуум (разделяться ими) ==> он уникален в восприятии конкретного индивидуума ==> субъективен
Смысл объективен, субъективно восприятие и выражение смысла. Попросите двух человек пересказать одну и ту же книгу. Каждый из них воспринимает и передает книгу по-своему, но это не означает отсутствия книги или ее содержания.

c ==> слова хотя бы иногда передают смысл ==> смысл можно передать посредством слов. это противоречит утверждению d
Слова могут указывать, но передать смысл они не могут. «Дао, выраженное словами, - не есть подлинное Дао» (Лао-Цзы) (а также: «слово произнесенное - есть ложь»).

d ==> слова не могут наполняться смыслом. они бессмысленны. это противоречит утверждению c
Слова имеют (свой!) смысл... Словами можно подвести к пониманию смысла предмета/сущности/действия/...

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

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

Ответ на »сообщение 4273« (AVC)
___________________________
Я исхожу из простого положения: «Все имеет смысл», наша задача понять этот смысл. Даже приступая к анализу требований пользователей, первое, что нужно сделать, на мой взгляд, это понять истоки тех или иных требований...
Пока я понимаю Вас примерно так.
(Исходя из допущения, что можно пока ограничиться прикладным программированием.)
Приступив к работе над новой задачей, после изучения требований пользователей, Вы не броситесь заниматься проектированием, а сначала хорошо обдумаете саму задачу. Конечно, мышление трудно (если вообще) алгоритмизируется, но, наверное, Вы будете анализировать задачу, выбрасывая из ее постановки все "несущественные" элементы и упрощая ее таким образом до тех пор, пока выбрасывать станет больше нечего. :)
Анализировать требования пользователей и задачу я не буду... наоборот, постараюсь уменьшить поступление информации извне. Эта стадия «рождения образа»... Присмотритесь к тому, как работают художники, музыканты, писатели... Они запираются в своей квартире или на даче... избегают общения... уходят в себя... Они рождают образ... будущего произведения. Образ или первая семантическая модель... суть данного этапа. Нужен Луч...

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

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

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

Дальше Вы, вероятно, задумаетесь о реализации.
При этом будете выбирать, исходя из практических соображений, между использованием чужих компонентов и написанием своего кода
После рассмотрения модели наступает этап проектирования, который позволяет приблизить модель к реализации. На заключительных стадиях проектирования принимаются решения и о компонентах, в том числе. А далее идет стадия планирования, когда принимаются решения о том, кто и когда будет выполнять ту или иную работу, что можно/нужно заказать/поискать на стороне, что будем делать сами. Определяются сроки, уточняются бюджеты и т.д. Далее наступает стадия реализации, потом эксплуатации. То есть, получаем «жизненный цикл».

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

От качества выбранного Вами инварианта зависит устойчивость Вашей модели и, следовательно, программной системы
Не только устойчивость... практически все потребительские свойства будущего продукта заложены в первоначальном образе... Собственно, поэтому... так важно понять смысл, иначе велика вероятность стать рабом своего же творения...

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

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

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

Интересно, действительно ли это все равно?
Ведь ведущая роль синтаксиса при компиляции (т.н. syntax-driven compilation) -- почти догма...

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


Понимаю, что параллель с иерархией классов тут не совсем корректна, но все же…

Зато, IMHO, здесь полная параллель с каркасом.
Лексическая и синтаксическая составляющая -- каркас, а генерация кода -- специфическая часть (для каждого нового процессора).

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

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

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

Интересно, действительно ли это все равно?
Ведь ведущая роль синтаксиса при компиляции (т.н. syntax-driven compilation) -- почти догма...


Понимаю, что параллель с иерархией классов тут не совсем корректна, но все же…

Зато, IMHO, здесь полная параллель с каркасом.
Лексическая и синтаксическая составляющая -- каркас, а генерация кода -- специфическая часть (для каждого нового процессора).

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



http://www.embedded.com/story/OEG20010725S0103
<...>


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

Согласен, что до "столбовой дороги" Меллору пока далеко.
Но все же не стоит упускать его "из виду".
AFAIK, Project Technologies Inc. (т.е. Шлаер, Меллор и т.д.) довольно далеко продвинулись в деле создания CASE-систем.
Им удалось выделить из UML разумное подмножество и довести его до уровня генерации кода прямо из модели (т.н. xUML -- исполняемый UML).
Вообще, к Меллору у меня симпатия. :)
В 90-х годах у нас был издан перевод книги Shlaer, Mellor "Object lifecycles: modeling the world in states". Меня тогда поразила конкретность содержания книги, в противовес "расплывчатости" Буча.

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

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

a) "смысл не может быть общим"
b) "смысл каждый открывает сам"
с) "слова, к сожалению, не всегда передают смысл"
d) "нельзя передать смысл"
e) "вкладывать [в слова] смысл нельзя"

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

a+b ==> один и тот же смысл не может принадлежать нескольким индивидуум (разделяться ими) ==> он уникален в восприятии конкретного индивидуума ==> субъективен.

c ==> слова хотя бы иногда передают смысл ==> смысл можно передать посредством слов. это противоречит  утверждению d.

d ==> слова не могут наполняться смыслом. они бессмысленны. это противоречит утверждению c.

e ==> слова полностью отделены от смысла ==> они сами по себе, смысл сам по себе. это противоречит утверждению c.

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

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

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

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

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


Если мы постоянно разрабатываем приложения для данной прикладной области, то можно накопить опыт и обобщить его в виде библиотеки классов или даже специального прикладного каркаса. Но такую библиотеку (или каркас), думается, не удастся создать на основании опыта одного приложения
Надо только помнить, что опыт – имеет «две стороны». С одной стороны, он позволяет быстрее получить решение, с другой стороны, он... замедляет процесс принятия решения. С одной стороны, он гарантирует получение качественного решения, а с другой стороны, «качество» может быть некачественным. В этом нет парадокса... все дело в уровне новизны проблемы (даже, казалось бы, в исследованной/изученной предметной области). Для примера, при решении новой задачи в Delphi можно воспользоваться либо готовыми компонентами, либо написать свои. Готовые компоненты – это чей-то концентрированный опыт, который может помочь нам в решении нашей задачи. Но! Компонент может быть много и среди них надо выбирать, что бы сделать хороший выбор, надо потратить время, на то, чтобы изучить их, проверить на совместимость с другими компонентами, обеспечить их соответствие требованиям задачи и т.д. Хорошо если выбор надо сделать из десятка компонент, хуже, если из сотни (качество анализа будет ниже, поскольку время, отпущенное на проект, ограничено, а, следовательно и глубина изучения каждого из многих компонент будет меньше). С другой стороны, выбрав какой-то из компонент, мы вынужденны положиться на то, что его автор не допустил серьезных ошибок, что у нас под рукой будут исходники, что мы сумеем в них разобраться за ограниченное время... Однако, авторы компонентов, как правило, стараются реализовать максимально большую функциональность (максимизация потребительских свойств), большая часть из которой может оказаться избыточной, а необходимая нам функциональность, при этом, может оказаться недостаточно полно и хорошо проработанной. Как следствие потребуется дополнительный код, «привязывающий» компоненты к задаче. В результате общее решение задачи может оказаться избыточно сложным, недостаточно надежным, громоздким и трудным в сопровождении (кто же гарантирует, что авторы будут поддерживать свои компоненты в новой версии Delphi или OS). При этом собственное решение может оказаться значительно проще и легче. Я совсем не призываю создавать каждую программу с нуля, нет... я ратую за продуманное и взвешенное решение.

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

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

Пока я понимаю Вас примерно так.
(Исходя из допущения, что можно пока ограничиться прикладным программированием.)
Приступив к работе над новой задачей, после изучения требований пользователей, Вы не броситесь заниматься проектированием, а сначала хорошо обдумаете саму задачу. Конечно, мышление трудно (если вообще) алгоритмизируется, но, наверное, Вы будете анализировать задачу, выбрасывая из ее постановки все "несущественные" элементы и упрощая ее таким образом до тех пор, пока выбрасывать станет больше нечего. :)
(Таким образом Вы, возможно, пришли к пониманию "склада" как "демпфера". Жаль, что я не понимаю значения этого слова. :( По немецки это, вроде бы, глушитель...)
Затем Вы отправитесь в "обратный путь", воссоздавая требования пользователя на основе полученного понимания. Но при этом "твердой землей", инвариантом, остается приобретенное путем анализа понимание, а не сами требования пользователя. Возможно, по этой причине изменение требований пользователя не окажется смертельным для проекта.
В результате этой "синтетической" стадии у Вас получится то, что можно было бы назвать "системой внутренних интерфейсов" (наверное, существует подходящий термин, но он мне сейчас не приходит в голову).
Дальше Вы, вероятно, задумаетесь о реализации.
При этом будете выбирать, исходя из практических соображений, между использованием чужих компонентов и написанием своего кода.
Допустим, Вам "повезло", и под рукой оказались достаточно качественные и подходящие к задаче чужие компоненты (для реализации).
Даже в таком случае потребуется некий промежуточный код ("прослойка"), приспосабливающий чужие компоненты к Вашим внутренним интерфейсам. Зато при изменении заимствованных компонентов (или при переписывании их самостоятельно) Вам достаточно будет изменить эту прослойку.
От качества выбранного Вами инварианта зависит устойчивость Вашей модели и, следовательно, программной системы.

Прошу прощения за такой вольный "полет фантазии".
Вопрос в том, соответствует ли он примерно Вашему способу работы над проектом?

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



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

А в чем собственно проблема? Другая реализация абстрактного класса (Stores, Views и т.д.) не обязана совпадать с "эталонной" по скрытым полям. Компилятор и загрузчик ориентируются только на экспротируемые поля. По крайней мере в случае указателей на записи, для них изменение размера структуры значения не имеет.