OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 16 Октябрь, 2019 09:51

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 62 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Пятница, 11 Май, 2012 11:57 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
наследование - это важнейшая часть ООП.


В структурном редакторе достаточно ли для наследования расширяемых записей (плюс переменные процедурного типа и табличные средства обеспечения полиморфизма)?

Или же необходимо наследование методов, т.е. нужны классы, содержащие помимо полей данных также и методы, и нужны интерфейсы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Пятница, 11 Май, 2012 13:17 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Info21 писал(а):
...
П.1 ничего добавить не может -- объективная реальность просто есть.
А вот в пунктах 2-4 комбинаторная мысль масс бьёт ключом.

В принципе согласен, но ООП это дополнительное средство структуризации ПО, и объективно требует дополнительных знаний и умений, и таки да в реальном программировании "комбинаторный" слой весьма толст, а вот канонический весьма тонок.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Пятница, 11 Май, 2012 20:26 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8184
Откуда: Троицк, Москва
Axcel писал(а):
... но ООП это дополнительное средство структуризации ПО, и объективно требует дополнительных знаний и умений, и таки да в реальном программировании "комбинаторный" слой весьма толст, а вот канонический весьма тонок.
Можно сказать, с этого и проект начался :)
Спецкурс весной 2001 г. был как раз про то, чтобы рассказать основы "программирования в большом". Только сразу оказалось, что проблемы ещё с основами алгоритмики :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Пятница, 11 Май, 2012 20:56 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3093
Откуда: Астрахань
Сергей Прохоренко писал(а):
Валерий Лаптев писал(а):
наследование - это важнейшая часть ООП.


В структурном редакторе достаточно ли для наследования расширяемых записей (плюс переменные процедурного типа и табличные средства обеспечения полиморфизма)?

Или же необходимо наследование методов, т.е. нужны классы, содержащие помимо полей данных также и методы, и нужны интерфейсы?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Пятница, 11 Май, 2012 22:17 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
О наследовании мы еще размышляем. Анализ положения дел в этой сфере показал, что в разных языках слишком по-разному эта часть реализована. То есть нет еще устоявшегося ядра (каковое имеется в процедурной части). Мы анализируем на предмет минималистской реализации.


Тогда подкину идейку.

Сначала немного критики сложившегося бардака. Пардон, "не устоявшегося ядра". :D Наследование с помощью "генеалогического дерева" классов - единственно возможное в текстоориентированном программировании. Но оно слишком запутанное, и вполне может быть заменено более адекватными механизмами в визуальном программировании (т.е., в структурном редакторе), например, таблицами. В дереве классов к одному набору данных и методов можно прийти разными путями. Необходимость придерживаться модели "генеалогического дерева" может заставить создавать уродливые промежуточные интерфейсы и классы, не отражающие предметную область, а лишь содержащие нужные данные и методы для производных классов. Это не более чем наборы и заготовки для конечных классов. Но чтобы сделать 10 конечных классов иногда приходится делать 15 промежуточных интерфейсов. Дерево классов разрастается и делается необозримым, а его содержимое всё хуже отражает предметную область. "Апофеозом" являются монструозные фреймворки .NET и Java, в которых произвольное нагромождение данных и методов дополняется отсутствием нормального мануала на русском языке (да и на английском так себе мануал).

Идея заключается в создании конструктора (wizard) классов, опирающегося на (отображаемую в табличной форме) реляционную базу данных переменных и процедур, содержащихся в модуле. В базе данных переменные и процедуры могут быть помечены классифицирующими признаками - для удобства поиска и фильтрации. Классы будет легко сравнить по содержимому, опираясь на запросы к реляционной БД.


Последний раз редактировалось Сергей Прохоренко Суббота, 12 Май, 2012 09:43, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Суббота, 12 Май, 2012 08:57 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Это в период выполнения так будет? Или что имелось в виду?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Суббота, 12 Май, 2012 09:44 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
Это в период выполнения так будет? Или что имелось в виду?


Нет. В процессе разработки программы (compile time).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Суббота, 12 Май, 2012 11:10 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Т.е. это не влияет на конструирование объектов (экземпляров классов)?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Суббота, 12 Май, 2012 14:39 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
Т.е. это не влияет на конструирование объектов (экземпляров классов)?


Не влияет. Оператор new - само собой.

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


Скорее о склеенном стоге соломы - нет единого стебля. При конструировании классов мы уже не связаны никакими родословными. Можно, например, скопировать "куски" от разных классов и сразу склеить намертво в новый класс, и при этом добавить ещё переменных и методов. Структурный редактор должен контролировать внутреннюю непротиворечивость полученной конструкции (возможность применения методов к объектам). Никакие последующие изменения в исходных классах уже не повлияют на новый класс. Можно (поскольку мы имеем дело с удобной реляционной базой данных!!!) автоматически отслеживать все изменения в исходных классах (программисту достаточно сконструировать запрос) и предлагать программисту внести соответствующие изменения в новый класс. СУБД можно вообще взять готовую, например, Microsoft Access со всеми ее замечательными "прибамбасами", а в структурном редакторе нужно сделать соответствующий шлюз.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Май, 2012 07:43 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
...
Владислав Жаринов писал(а):
Ну, а если попробовать определить структуру классов периода сочинения по-Вашему - то можно говорить о дереве, только "прошитом" (как каталожное в Линуксе за счёт жёстких ссылок)?..
Скорее о склеенном стоге соломы - нет единого стебля.
...
Ага... значит, схемы со сращением деревьев по листам или корням, как здесь?.. или можно сращивать также листы одних с узлами/корнями других?..

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Май, 2012 10:40 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
Ага... значит, схемы со сращением деревьев по листам или корням, как здесь?.. или можно сращивать также листы одних с узлами/корнями других?..


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

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


Проверки во время конструирования программы или компиляции: (1) объявлены ли в новом классе все необходимые поля, обрабатываемые при вызове всех его методов (выдача ошибки "нет поля или лишний метод"); (2) есть ли в новом классе поля, не обрабатываемые ни одним из его методов, кроме конструктора (выдача ошибки "нет метода или лишнее поле")?

Владислав Жаринов писал(а):
Сергей Прохоренко писал(а):
...
Можно (поскольку мы имеем дело с удобной реляционной базой данных!!!) автоматически отслеживать все изменения в исходных классах (программисту достаточно сконструировать запрос) и предлагать программисту внести соответствующие изменения в новый класс.
...
- так всё-таки полуавтоматически (т.к. с участием человека)? а как автоматически (когда среда сама поо изменениям структуры классов перестраивает запросы и инициирует их)?


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

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


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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Май, 2012 12:58 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
...
Владислав Жаринов писал(а):
Сергей Прохоренко писал(а):
...
Можно (поскольку мы имеем дело с удобной реляционной базой данных!!!) автоматически отслеживать все изменения в исходных классах (программисту достаточно сконструировать запрос) и предлагать программисту внести соответствующие изменения в новый класс.
...
- так всё-таки полуавтоматически (т.к. с участием человека)? а как автоматически (когда среда сама поо изменениям структуры классов перестраивает запросы и инициирует их)?
Полный автоматизм означал бы, что изменения в базовых классах автоматически приводят к изменениям в классах-потомках, что выводит процесс из-под контроля человека. Раз построенные запросы не нуждаются в перестройке, инициировать их можно автоматически. Но за программистом должно оставаться санкционирование (акцепт) предлагаемых запросом изменений.
Да, нужно уточнить, что сказанное относилось только к мониторингу. Решать по изменениям при такой схеме, конечно, должен человек (ибо м.б. потребоваться неформальное решение).

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

Сергей Прохоренко писал(а):
...
Преимущества следующие:
    ...
  • все изменения типов происходят в явном виде во время компиляции или до нее - под полным контролем программиста и среды разработки;
    ...
...
А динамически изменяются при исполнениии (за счёт указательной связности) уже экземпляры типов? Или как реализуются произвольные структуры времени исполнения?

И по реализации - как Вы видите, это делается на базе существующей среды (ББ, ВЛ-редактора, АО-системы)? или надо писать новую? И как тогда выглядит сам язык программирования? а спецификаций (формальных)?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Май, 2012 14:45 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
А динамически изменяются при исполнениии (за счёт указательной связности) уже экземпляры типов? Или как реализуются произвольные структуры времени исполнения?


Присвоение значения переменной типа "указатель" не есть изменение типа, а есть только присвоение значения переменной. Это, разумеется, происходит после компиляции - во время исполнения программы. Термин "динамический тип данных" не вполне корректен. Это не тип данных, а переменная, экземпляр типа.

Владислав Жаринов писал(а):
И по реализации - как Вы видите, это делается на базе существующей среды (ББ, ВЛ-редактора, АО-системы)? или надо писать новую? И как тогда выглядит сам язык программирования? а спецификаций (формальных)?


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Май, 2012 10:45 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
Никакие последующие изменения в исходных классах уже не повлияют на новый класс.
Имхо, нельзя этого делать, весь смысл наследования классов тогда пропадает...
Впрочем, наследовать лучше роли, а не классы целиком (то есть отдельные наборы интерфейсов со своими данными и методами). Тогда уходят все проблемы древовидной иерархии.

Сергей Прохоренко писал(а):
Проверки во время конструирования программы или компиляции: (1) объявлены ли в новом классе все необходимые поля, обрабатываемые при вызове всех его методов
Более важная проблема возникает в другом - когда пользователь библиотеки изменяет функциональность унаследованных интерфейсов (виртуальные методы). Тогда любое изменение библиотеки потребует от него соответствующей переделки своих внутренностей. И махнуть рукой на это будет нельзя, поскольку вся система в целом будет использовать эту функциональность.

А для моих задач более актуальна поддержка автоматического обновления экземпляров при изменении класса. Нетривиальная проблема. ;)
Банальное изменение структуры используемых в библиотеке классов приводит к проблемам пользователя. За примерами далеко ходить не надо. Вон, в VCL Дельфи раньше был TSpin, а теперь извольте использовать связку TEditor + TUpDown. И всё, старый проект под новую версию Дельфи переносить - уже геморрой не маленький.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Май, 2012 13:18 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Alexey_Donskoy писал(а):
Сергей Прохоренко писал(а):
Никакие последующие изменения в исходных классах уже не повлияют на новый класс.
Имхо, нельзя этого делать, весь смысл наследования классов тогда пропадает...


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

Alexey_Donskoy писал(а):
Как разрулить подобные проблемы даже при Вашем подходе, не представляю...


Как раз при моем подходе их и можно разрулить. Что бы не придумывал разработчик библиотеки, результаты его творчества передаются в программу пользователя "по значению" - явно и под полным контролем программиста. Дальнейшие изменения библиотеки полуавтоматически мониторятся и попадают в программу только с явного согласия программиста. Это лучше согласуется с компонентным программированием, когда каждый отвечает за свой модуль и не доверяет слепо вендору.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Смысл ООП
СообщениеДобавлено: Среда, 16 Май, 2012 14:44 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8184
Откуда: Троицк, Москва
Композицию надо почаще применять вместо ООП.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Май, 2012 15:13 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
смысла собственно в обычном наследовании я пока не вижу (когда всё, что в будущем намудрит разработчик библиотеки, автоматически попадёт в программу без какого-либо контроля со стороны ее разработчика).
Не совсем о том речь, может быть?
Я говорю о том, что есть система. Которой пользуются пользователи и делают на ней свои проекты. Занимаясь тоже своего рода программированием (на встроенных языках). Примеры: Автокад, 1С, RS-bank, SCADA любая, SoftLogic системы программирования контроллеров и т.д. и т.п.

Естественно, система развивается, и в очередной версии вводится новая функциональность и изменяется старая.
Как Вы представляете импорт проекта из старой версии в новую "с явного согласия программиста"?

Сергей Прохоренко писал(а):
Это лучше согласуется с компонентным программированием, когда каждый отвечает за свой модуль и не доверяет слепо вендору.
За какой такой модуль может отвечать инженер, рисующий чертёж в Автокаде?! :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Май, 2012 18:11 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Alexey_Donskoy писал(а):
Сергей Прохоренко писал(а):
смысла собственно в обычном наследовании я пока не вижу (когда всё, что в будущем намудрит разработчик библиотеки, автоматически попадёт в программу без какого-либо контроля со стороны ее разработчика).
Не совсем о том речь, может быть?
Я говорю о том, что есть система. Которой пользуются пользователи и делают на ней свои проекты. Занимаясь тоже своего рода программированием (на встроенных языках). Примеры: Автокад, 1С, RS-bank, SCADA любая, SoftLogic системы программирования контроллеров и т.д. и т.п.

Естественно, система развивается, и в очередной версии вводится новая функциональность и изменяется старая.
Как Вы представляете импорт проекта из старой версии в новую "с явного согласия программиста"?


Мы не говорим об унаследованном софте и программировании на встроенных языках. Речь идет только о структурном редакторе и совместимых с ним библиотеках. Хотят того разработчики библиотек или не хотят, но им придется следовать идеологии структурного редактора. Программист может одновременно использовать классы, реализованные хоть в новой версии библиотеки, хоть в старой. Они сохранятся в программе в том виде, в котором они были изначально в соответствующих версиях. Захочется использовать функциональность новой версии - да ради бога! Нет никакого "импорта проекта из старой версии в новую" - просто новые поля и методы копируются в программу. Нет никакого тяжеловесного фреймворка - в программу копируется только то, что реально используется. Да, в приложениях что-то будет дублироваться, но реально независимых приложений не так уж много. Разумеется, при желании можно комбинировать этот подход с обычным наследованием - использовать устоявшиеся библиотечные модули от третьей стороны.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2012 07:07 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
Мы не говорим об унаследованном софте и программировании на встроенных языках... Если же речь идет не о разработке независимых приложений, а лишь о программировании на встроенных языках, то проблемы совместимости целиком на совести разработчиков встроенных языков.
Чем, по большому счёту, один вид программирования отличается от другого? Разве что языками.
Вы хотите решить проблему для одного языка и замести под ковёр для другого языка. Это порочный подход.
Хорошее решение (тем более претендующее на универсальность) должно работать на всех уровнях взаимодействия человек-техника.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2012 09:32 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Хотите избавить встроенный язык (DSL) от проблем, присущих ООП, - встраивайте его в структурный редактор, если, конечно, архитектура структурного редактора будет открытой, или DSL признан стОящим усилий по интеграции. В структурный редактор можно, в принципе, добавить и вкладку с новым представлением, и инструментальные панели. А решать проблемы разработчиков фреймворков и автокадов, которые свои интересы ставят выше интересов клиентов, я не обещал. В конце концов, они и сами могли бы применить в своих инструментах тот же подход, что мною предлагается для структурного редактора.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 62 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB