OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 13 Декабрь, 2019 05:36

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




Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу Пред.  1, 2, 3, 4, 5
Автор Сообщение
СообщениеДобавлено: Суббота, 23 Ноябрь, 2019 12:24 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 680
Всё это неконкретно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Ноябрь, 2019 13:11 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
PSV100 писал(а):
Таким образом, понятие метатипа, фактически, стирает границы между compiletime и runtime, облегчая задачи и для возможного "интерактивного" devtime, давая почву для разговора и в сфере потенциального аля "SPARK", максимальная однородность технологического языка (как путь уменьшения меры неоднородности).

Что-то мне это СИЛЬНО напоминает смешанные вычисления Ершова, написанные, дай Бог памяти, в первой половине 80-х.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Ноябрь, 2019 13:55 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1343
Откуда: Украина, Киев
PSV100 писал(а):
Упомянутые выше метатипы в Delphi видятся как некое фундаментальное зерно в качестве попытки снять разнородность в "раздувании синтаксиса", и, в целом, в раздувании понятийного аппарата в тезаурусе языка. В самой Delphi концепцию не развили (даже можно допустить, что не успели, затем начался Net...). Напрашивается обобщение для метатипов как универсальное метапредставление, в т.ч. и как аналог проекций типов (смежное математическое понятие рядом со структурами) в функциональных языках. И полиморфные параметры типов по сути также являются теми же метатипами, с такими же возможностями. Причём "шаблоны" должны быть предназначены как и для compiletime-вычислений, так и для runtime-динамики.
Попробую, в порядке пятничного бреда, направление мысли в общих чертах на примерах...
Net в Delphi как начался, так и быстро закончился. Ни в одном проекте не встречал, что-бы это использовалось. Бытовало мнение, что если надо писать под Net, то нет ничего лучше чем C#
А метатипы весьма полезны, я их активно использовал. Очень выразительные получаются фабрики экземпляров классов.

В Delphi другое "началось"... FireMonkey, очень неоднозначно воспринимаемая сообществом. Многие говорят, что эта технология очень сырая.
Всё, вроде, задумано правильно, но работает очень странно, ужасные провалы производительности...
Старый добрый VCL по-прежнему доступен и если нужна скорость разработки и быстрое отзывчивое приложение, использовать VCL всё же предпочтительнее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Ноябрь, 2019 14:08 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1343
Откуда: Украина, Киев
budden писал(а):
Но нет, обязательно нужно было раздуть :)
Вот-вот, тежело осилить весь этот поток. Когда пробежались по всему, что можно было упомянуть :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Ноябрь, 2019 16:06 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 680
Comdiv писал(а):
при грамотной декомпозиции сущность является не просто хранилищем данных, а предоставляет некий интерфейс и хранит в себе некоторые инварианты.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Ноябрь, 2019 19:05 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1343
Откуда: Украина, Киев
budden писал(а):
В том же Дельфи уже есть ограничение - в сериализацию попадают только published свойства.
И лишь для наследников класса TPersistent


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Ноябрь, 2019 20:36 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Ярослав Романченко писал(а):
budden писал(а):
В том же Дельфи уже есть ограничение - в сериализацию попадают только published свойства

И лишь для наследников класса TPersistent

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Ноябрь, 2019 20:37 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Ярослав Романченко писал(а):
PSV100 писал(а):
Упомянутые выше метатипы в Delphi видятся как некое фундаментальное зерно в качестве попытки снять разнородность в "раздувании синтаксиса", и, в целом, в раздувании понятийного аппарата в тезаурусе языка. В самой Delphi концепцию не развили (даже можно допустить, что не успели, затем начался Net...).

Net в Delphi как начался, так и быстро закончился. Ни в одном проекте не встречал, что-бы это использовалось. Бытовало мнение, что если надо писать под Net, то нет ничего лучше чем C#

Имелось ввиду, что с Net-ом (кажись, после Delphi 7) "начался" уже типовой мэйнстрим, с раздуванием языка и платформы характерными "фичами"...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Ноябрь, 2019 20:40 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
budden писал(а):
Если такая дыра есть, то её причиной является наследование через границу модулей, которое нарушает модульность уже само по себе. Даже если её нет, проблема того, что "наследование нарушает инкапсуляцию", давно известно, а инкапсуляция - это свойство модульности. Так что если не в точном смысле, то во всяком случае близка к тому, что с модульностью в Обероне и так не слишком хорошо. Тут как бы можно задать резонный вопрос - а есть ли нам ещё, что беречь, или у нас уже всё равно нет модульности?

Имхо, модульность по-обероновски хотя бы "помодульнее", чем в традиционном ООП.

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

Обероновская попытка притянуть понятие модулей в программную инженерию выглядит поприличнее, что ли, на фоне возможных альтернатив. Отсутствие аналога доступа как "protected" из "обычного" ООП подразумевает некую завершённость или целостность представления выделенной роли в разрезе модуля, хоть последняя может иметь абстрактную или предполагать расширенную форму. Иными словами, операции с доступом через "*" и "-" в случае их возможного "расширения" в других модулях не предполагают вмешивание во внутренние дела, определенные внутри модуля. Когда как традиционный "protected" в ООП, всё же, методологически допускает некое вмешательство в исходный функционал (роль), хоть якобы мол "со знанием дела".
budden писал(а):
* загружаем модуль А с типом-записью Аа. В нём хранится список указателей на Аа в глоб.перем Сп
* В модуле Б есть тип-потомок Аб типа-записи Аа, с переопределёнными методами
* Кладём экземпляр Аб в Сп
* Выгружаем модуль Б.

Два вопроса:
* Сможем ли мы выгрузить модуль Б?
* Что случится при вызове переопределённого метода от Аб?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Ноябрь, 2019 20:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Валерий Лаптев писал(а):
PSV100 писал(а):
Таким образом, понятие метатипа, фактически, стирает границы между compiletime и runtime, облегчая задачи и для возможного "интерактивного" devtime, давая почву для разговора и в сфере потенциального аля "SPARK", максимальная однородность технологического языка (как путь уменьшения меры неоднородности).

Что-то мне это СИЛЬНО напоминает смешанные вычисления Ершова, написанные, дай Бог памяти, в первой половине 80-х.

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

Кстати, в статейке ниже насчёт смешанных вычислений любопытно отмечено:
http://www.computer-museum.ru/books/n_ershov/2_ershov_sv.htm
Цитата:
Таким образом, в определенном смысле сбылось предсказание Н. Н. Непейводы: у нас имелся один из самых мощных смешанных вычислителей, но не было программ, к которым его можно было бы успешно применить, поскольку, даже разрабатывая универсальную программу, программист не задумывается о том, насколько она пригодна для специализации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Ноябрь, 2019 07:08 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Не. Идея смешанных вычислений в том, чтобы для программы не различались этапы компиляции и выполнения (были "однородными").
Этап компиляции - тоже вычисления. Поэтому - смешанные.
Удивительно, как это все воплощается в С++ через десятилетия.
Поэтому "построение структур данных, однородно как в runtime, так и compiletime" - это как раз оно и есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Ноябрь, 2019 19:54 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Валерий Лаптев писал(а):
Не. Идея смешанных вычислений в том, чтобы для программы не различались этапы компиляции и выполнения (были "однородными").
Этап компиляции - тоже вычисления. Поэтому - смешанные.
...
Поэтому "построение структур данных, однородно как в runtime, так и compiletime" - это как раз оно и есть.

В общем-то, "это как раз оно", если уж предельно обобщать суть исходного понятия смешанных вычислений. Первично под последним подразумевалась трансформация (автоматическая) представления программы в иной вид, где часть вычислений осуществляется до runtime. Алгоритмическая модель, заданная разработчиком как исполнительные инструкции для runtime, переводится в иную форму вне осознанности самим разработчиком, новая форма в результате преобразований может иметь совсем другой вид, вплоть, фактически, на ином технологическом языке (к примеру, может быть осуществлён методологический переход к понятию автоматов согласно необходимой специализации, в итоге конечная "остаточная" программа может представлять из себя лапшу из goto (вместо исходной "структурности") -- ничего подобного может не быть в исходном "тезаурусе" моделирования у разработчика, у него мозг может сломаться, если вдруг попытается "вручную" выстроить нечто подобное, или вопрос насчёт корректности полученной "выкрученной" модели окажется весьма не простым, и т.д.).
Когда как "обобщённые алгоритмы и структуры данных, однородно как в runtime, так и compiletime" -- осознанная деятельность разработчика, непосредственный репертуар моделирования. И результаты мета-моделирования в compiletime как подготовка исполнительных runtime-инструкций в дальнейшем могут быть поданы на вход смешанному вычислителю. В идеале, видимо, в современных условиях часть репертуара "ручных" compiletime-вычислений может быть функционалом и смешанного вычислителя.
Валерий Лаптев писал(а):
Удивительно, как это все воплощается в С++ через десятилетия.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Ноябрь, 2019 22:10 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2639
Откуда: Россия, Ярославль
Копирайчу :mrgreen: , если что
Цитата:
29 Sep 2015
В дополнение необходимо отметить, что можно обоснованно выделить design-time в отдельную категорию, но не как процесс в голове разработчика, а чисто утилитарно, опираясь на процесс кодирования. Здесь можно описать автокомплит, автоподсветку (как уже реализованные программы), программирование макросов ide, генерацию схем БД и ДРАКОН-схем, и так далее. То есть, уточненная последовательность одной итерации жизненного цикла программы будет представлена как: design-time -> compile-time -> load-time -> link-time -> init-time -> run-time -> close-time -> death-time.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Ноябрь, 2019 06:44 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Класс!!!


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

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


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

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


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

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