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

Ответ на »сообщение 2960« (AVC)
___________________________
>>> Спасибо, я не знал, что типы активных объектов не расширяемы

Если не расширять, то нерасширяемы. :-)

Т.е. все-таки расширяемы?

Ответ на »сообщение 2961« (AVC)
___________________________
>>>С тех пор у меня развилось сильное "подозрение", что активность (как КА, так и поток) не стоит мешать с наследованием.
Конечный автомат практически не требует наследования. В данном случае удобно поступать рекламируемым тут методом сборки: стоит заменить таблицы и получим другой автомат без введения новых типов.
А с активностью нужно разбираться так же, как с данными: если есть инвариантное ядро, его удобно реализовать в виде общего предка.
Каков алгоритм КА?
1.Получить сигнал.
2.По сигналу и текущему состоянию найти строку в таблице переходов.
3.Выполнить процедуру, указанную в строке.
4.Установить состояние, указанное в строке.
Может ли этот алгоритм изменится?
Если речь идет о КА, то нет - он соответствует математическому определению КА.
Когда я описывал технологический автомат, то унаследовал его от КА, т.к. описал его, как частный случай КА.

Ответ на »сообщение 2960« (AVC)
___________________________
>>> Спасибо, я не знал, что типы активных объектов не расширяемы

Если не расширять, то нерасширяемы. :-)

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

>>>А можно по-подробней обо всём этом?

Конечно, можно.
Только немного позже: надо вспомнить и еще раз обдумать ту ситуацию, а сейчас -- рабочая суета.

Ответ на »сообщение 2961« (AVC)
___________________________
Мои проблемы были связаны с тем, что я создал иерархию классов устройств, причем активность (не в смысле потоков, а в смысле КА; хотя это, ИМХО, родственная активность) "зашил" в эту иерархию.
И все было хорошо, пока одному из устройств не пришлось сменить КА.
А это оказалось нелегко.
С тех пор у меня развилось сильное "подозрение", что активность (как КА, так и поток) не стоит мешать с наследованием.
А можно по-подробней обо всём этом?

Ответ на »сообщение 2878« (Сергей Перовский)
___________________________

У меня работает объект-КА, причем он является наследником абстрактного динамического объекта, который, в свою очередь унаследован от TComponent. Но это все детали реализации. От КА у меня создан всего один наследник - Технологический КА, в основном наследование не требуется, необходимо только заполнить таблицу и можно описать любой КА не создавая новых типов.
Хотелось бы узнать подробнее, в чем Вы видите проблему - мне это действительно важно.

Мои проблемы были связаны с тем, что я создал иерархию классов устройств, причем активность (не в смысле потоков, а в смысле КА; хотя это, ИМХО, родственная активность) "зашил" в эту иерархию.
И все было хорошо, пока одному из устройств не пришлось сменить КА.
А это оказалось нелегко.
С тех пор у меня развилось сильное "подозрение", что активность (как КА, так и поток) не стоит мешать с наследованием.

>>>Или Вы владеете неким секретом, как ASU.
Этот секрет называется системным анализом :)

Это да.
Системный анализ -- вообще отдельная и интересная тема.
Была в свое время интересная ветка, которую вел ASU.
К сожалению, не все переносимо из опыта одного человека в опыт другого. :(

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



>>>...возникают проблемы с наследованием. По сходной причине немного сомневаюсь в активных объектах...

Это распространённое заблуждение. Например, Б. Мейер когда выступал со своей лекцией в ННГУ про активные объекты то же самое сказал. На самом деле, никакой проблемы нет по той простой причине что единицей расширения (наследования) являются DEFINITION-ы, а не типы активных объектов. Типы активных объектов не расширяемы.

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

Ответ на »сообщение 2947« (Илья Ермаков)
___________________________
>>>А вот повторное использование через ООП часто делается очень неудачно и нарушает гибкость программной системы.
+1
Более того, я Вам приведу сотни примеров того, что "часто делается очень неудачно". В этом смысле ООП далеко не одиноко :)
Вот только вывод из этого утверждения можно сделать только один: ООП, как и любая другая парадигма программирования не освобождает от необходимости думать.
Поскольку ООП на данный момент парадигма очень распостраненная, а общий уровень программистов очень низок, примеров "очень неудачного" и просто кошмарного кода можно привести сколько угодно.

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

Ответ на »сообщение 2950« (Илья Ермаков)
___________________________
Однако при этом мы явно коммутируем методы для повторного использования. Это подобно ООП в классическом Обероне.
не понято... у меня такое осчусчение, что вы не в курсе...

Ответ на »сообщение 2955« (Илья Ермаков)
___________________________

Ну, тогда жаль. "Вульгарное ООП всюду дотянулось" :-)

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

Кроме того, в ООП всё вертится вокруг изменения состояния объектов, что невозможно в Хаскелле.

Так что утверждение о ООП-вульгаризации Хаскелла безосновательно! ;о)