Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 23:21

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Forth + Lazarus IDE
Автор Сообщение
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
KPG писал(а):
Какой глубинный смысл этих ежемесячных видео-тусовок? (Forth2020)

Да особо никакого. Это я сыронизировал над Silicon Valley FIG - раз просили таблицу, то вот таблица, плюс еще TChart. Видеочаты - не причина, а признак движения вперед. Если движения нет, видеочат не спасет.

В Forth2020 по мотивам моей лекции уже сделали процессор... прототип, если точнее. Но сам факт обнадеживает.
Сообщение Добавлено: Ср июл 21, 2021 17:52
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Hishnik писал(а):
Это задание на июль 2021 года от SVFIG. Можно я туда уже не пойду? :)

Какой глубинный смысл этих ежемесячных видео-тусовок? (Forth2020)
(вместо или совместно представвления каких то презентаций и в виде текстового материала)
Сообщение Добавлено: Ср июл 21, 2021 17:00
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Еще немного кот-иона (с лаположительным зарядом)...
Это задание на июль 2021 года от SVFIG. Можно я туда уже не пойду? :)


Вложения:
cation02.png
cation02.png [ 200.39 Кб | Просмотров: 11527 ]
Сообщение Добавлено: Ср июл 21, 2021 01:03
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
О, началось интересное! :) Ну надо же почаще выходить к людям, чтобы опробовать формулировки. А то прямо жалко читать такой накопленный "крик души", который было явно не с кем обсудить. Но я, тем не менее, это слегка обработаю хищническими лапками :)

Wlad писал(а):
представление понятия "жизненного цикла" сущности, выделенной при анализе системы

А вот тут "жизненный цикл сущности" в каком контексте применен? Если брать классическое entity, то... где оно в Форт-системе? Не рассматривать же как сущность число на стеке или сам стек. Или же под системой понимается тот программный продукт, который разработан с помощью Форта (форт-системы)... но тогда при чем здесь инструментальное обеспечение? Мало ли какие там конкретные тактические решения. В потоке можно запускать и просто долго выполняющийся расчет, чтобы не блокировать GUI, при таких видах простых взаимодействий системный анализ - это из пушки по воробьям.

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

Пусть даже так, нет же принципиального запрета на использование потоков в приложениях, которые в явном виде потоков не требуют. А чтобы увидеть потоки в оконном форт-приложении (и не обязательно форт- ), достаточно посмотреть на его работу. Идет расчет, а UI при этом реагирует. Без разделения на потоки варианты такие:
1) Пока Форт не досчитает длинные циклы - программа не реагирует.
2) В циклы (по какому принципу?) вставляется Application.ProcessMessages. Да уж.
3) Программист уведомляется, что он должен сам вставлять в циклы на Форте Application.ProcessMessages.
Любой из трех вариантов выглядит несерьезно.

Wlad писал(а):
Но, построение СИСТЕМЫ - НЕ "нахождение" набора алгоритмов!


Построение системы - это большой пласт работы с привлечением множества специалистов. И целая наука "системный анализ". А уж проектирование программной системы - это навскидку 2-3 больших и абстрактных стандарта. Алгоритмы тут на несколько уровней иерархии ниже, в части "для реализации способа решения задачи X используется следующий алгоритм:".

Wlad писал(а):
Нам нужно так изучить и построить модель нашей прикладной области, что бы алгоритм получался/"вытекал


Как это там было про мышек, которым было предложено стать ежиками? :)

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


Так что системой-то в данном случае является? Приложение с динамически настраиваемым GUI? Это не конечный продукт, это инструмент, для которого порядок проектирования совершенно другой, и никакие жизненные циклы объектов выделять не надо. Постановка задачи на разработку такой IDE определяется практикой применения подобных ей продуктов, откуда собраны use cases, к которым, после выбора из существующих (!) вариантов, добавлена конкретная IDE Lazarus, принесшая свои правила и ограничения.

Wlad писал(а):
Это трудно понять и принять в начале.

Так обычно начинается пропаганда секты :) "Не уверуешь - не увидишь" :)

Wlad писал(а):
Но зато потом вы увидите, как ваши программы станут НА ПОРЯДКИ более надёжными, расширяемыми и богатыми функционально.

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

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

Есть понятие архитектуры приложения, и там все видно. А когда архитектура из двух потоков с описанным API (Evaluate(string) в одну сторону и FIFO с сообщениями в виде структуры в другую), запутаться в этих двух соснах можно только специально.
Сообщение Добавлено: Ср июл 14, 2021 01:31
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
vikt писал(а):
Странно, у всех примерно одинаковые проблемы, хоть и разные языки и операционные системы.
А - с какой радости им быть ДРУГИМИ, если все - так и продолжают мыслить в категориях "взаимодействующих процессов", когда перемешиваются понятия из совершенно РАЗНЫХ семантических уровней представления системы, и когда совершенно частное (даже - ограниченное) представление понятия "жизненного цикла" сущности, выделенной при анализе системы, натянуто, как сова на глобус, на ВСЁ множество возможных решений?!
У таких "потоков" ПРАКТИЧЕСКИ НИКОГДА не осмысливается ХОЗЯИН того, что собой реализует этот поток.

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

До сих пор большинство разработчиков проектируют и разрабатывают программы (и - даже СИСТЕМЫ!), как "решения задач", где алгоритмы существуют (придумываются) не как результат взаимодействия элементов СИСТЕМЫ объектов прикладной области, а - просто, как "стишок" из "описания шагов решения"/"алгоритма".
До сих пор алгоритм остаётся самоценной сущностью, существующей первично, как "набор шагов по достижению результата".
По аналогии: многие - просто не додумываются, что текущая река, вращающая лопасти водяной мельницы, не существует в вакууме, а течёт по ложу реки!
Но, построение СИСТЕМЫ - НЕ "нахождение" набора алгоритмов!
В правильно построенной СИСТЕМЕ, алгоритм - вторичен. Нам надо так построить систему - "выложить ложе реки", что бы вода просто НЕ СМОГЛА течь ПО-ДРУГОМУ и исправно "крутила колесо нашей водяной мельницы". Нам нужно так изучить и построить модель нашей прикладной области, что бы алгоритм получался/"вытекал" ЕСТЕСТВЕННЫМ ОБРАЗОМ ИЗ НАЙДЕННОГО МНОЖЕСТВА ВЗАИМОДЕЙСТВИЙ ЖИЗНЕННЫХ ЦИКЛОВ СУЩНОСТЕЙ НАШЕЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ!
То есть, по своей сути, "алгоритмы решения" - просто частности, "побочные следствия", вытекающие из общего найденного закона функционирования всей модели системы, выраженной из частных законов и последовательностей жизненных циклов объектов, определённых нами, в нашей системе.
Это трудно понять и принять в начале. Покажется, что будет "много лишней работы". Но зато потом вы увидите, как ваши программы станут НА ПОРЯДКИ более надёжными, расширяемыми и богатыми функционально.
Вам просто нужно будет использовать силу течения вашей текущей "воды".
Скорее всего, вы сможете это делать не только для решения первоначальной задачи ("вращать колесо мельницы" :) )

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

Так откуда же будут ДРУГИЕ проблемы? :)
Сообщение Добавлено: Вт июл 13, 2021 02:43
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Странно, у всех примерно одинаковые проблемы, хоть и разные языки и операционные системы.
В андроид еще осложняется тем, что основной поток приложения невозможно приостановить,
чтобы принять ввод данных. Пришлось организовывать выполнение форт программ в новом потоке,
и заниматься синхронизацией этих потоков. Все это привело к задержке проекта,
которым я занимаюсь здесь, в своем блоге.
Я решил примерно так.

Перед вызовом expect, производится настройка ввода.
например, вызов
0 inputTuning настраивает работу expect как в обычном терминале.

1 4 1 inputTuning ( textFieldNumber , buttonActionNumber , functionNumber -> )
В этом случае expect приостановит работу программы и продолжит
после нажатия четвертой кнопки и считает текст из текстового поля номер 1.
Сообщение Добавлено: Вт июл 13, 2021 01:33
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Wlad писал(а):
Не для того, что бы "моё слово было последним" ! Просто - вдогонку, хотя и говорят, что "не делай добра - не будет зла" ...

Ну что уж прямо за отношение! Форум на то и форум, чтобы обсуждать, и отнюдь не факт, что вот прямо все должны иметь одинаковую точку зрения, одинаковый набор навыков, одинаковую специфику и прочее. Тогда все сведется к редкой унылой констатации того, что "DUP дублирует число на вершине стека", потому что больше-то обсуждать нечего. А продуктивное обсуждение может возникнуть практически на любой основе. Как в той самой шутке/притче, что спросить на форуме, как надо делать, обычно означает не получить ничего, но вот написать первый попавшийся, даже неправильный, вариант - хороший способ получить вал ответов, среди которых будут и правильные.

Wlad писал(а):
Обратите внимание ещё на такой класс, как TAction.
Не знаю, есть ли он в Lazarus-е и, если есть, то также он реализован, как в VCL, но в Дельфе он позволяет получать иногда очень красивые и рациональные решения.

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

Конкретно здесь проблема программирования лежит в другой плоскости. И явно необходимо обозначить переход от поколения "перед Delphi" к "Delphi, C++ Builder и другие RAD tools". Итак, что у нас было. Был цикл GetMessage - TranslateMessage - DispatchMessage. Был обработчик сообщений, у которого самый редактируемый пункт был фрагмент, относящийся к wm_command. Почему так - потому что написать функцию было недостаточно. Функция могла вызываться только в обработчике wm_command, который принимал сообщение со своим id, а для этого нужно было описать еще и элемент, который это сообщение генерировал. Поэтому добавление новой функции сопровождалось рутинными действиями "copy-paste кода в обработчике с заменой id и имени вызываемой функции, далее copy-paste кнопки с заменой генерируемого id, а заодно координат и надписи". Чревато ошибками из-за невнимательности.

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

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

Заходим с другой стороны. Вот есть форма и кнопка. Кнопка что-то делает, но хотелось бы поменять ее действие без перекомпиляции всего. Решение "лобовое в стиле Дельфи" - рядом с кнопкой положить выпадающие списки, чекбоксы, поля и прочее, что будет ее настраивать. Это ситуация, когда лечение хуже болезни - на один виджет нужно еще 5-10. Что можно от Форта? А пусть кнопка запускает на выполнение строку на Форте. Тогда будет достаточно отредактировать эту строку, чтобы изменить функции кнопки в очень широких пределах. Нужно, конечно, где-то держать эту строку, и естественно, нужна Форт-машина.

Теперь переходим к сути проекта. Допустим, у нас 10 кнопок, и, очевидно, 10 строк. Нажали button1 - выполнилась str1. Нажали button2 - соответственно, str2. В тексте программы... хмм, ладно, 10 кусков кода с именами button1clicked, button2clicked... button10clicked. Во всех почти одно и то же, только меняются имена строковых переменных. Оно может быть сделано и через TAction, но все равно - куда деваться от нарастающего кома обработчиков? А если кнопок 100? А если еще выпадающие списки? А поля редактирования?

Напрашивается решение - массив кнопок. Массив можно инициализировать в цикле... правда, есть одна объективная тонкость - там нужно указать обработчик, скажем, onClick. Каждой кнопке. Это что, для 100 кнопок нужно написать 100 обработчиков? Которые будут одинаковые, за исключением той строки, которые они будут запускать. Ну явно не то.

Проблема с генерированием в рантайме нескольких компонентов не нова. Например, в Qt 4.x еще был такой компонент signal mapper (в 5.x его почему-то объявили устаревшим, хотя все равно собирается). Он обеспечивал простую вещь - если создано N виджетов одного типа, то каждый виджет подключался к этому signal mapper, который сигнал от него преобразовывал в пару "сигнал + индекс". Поэтому signal mapper обеспечивает подключение всех кнопок к одному обработчику, сообщая ему при этом, какая именно кнопка сделала onClick. В руководствах оно описано достаточно подробно.

Для Delphi/Lazarus существует подобное по сути решение, только signal mapper там отсутствует. Зато примеры с генерированием вполне однозначны. Например, если нужно создать 10 кнопок с цифрами для калькулятора, то не нужно писать 10 обработчиков. Достаточно написать один, но.... обеспечив ему идентификацию конкретного объекта, который его вызвал. Раньше такой проблемы не было, потому что связь виджет-кнопка была явной. Ну и рекомендации на этот случай именно те, которые я описал - унаследовать класс, добавив ему поле "id экземпляра aka индекс в массиве". В переопределенном конструкторе довольно легко сделать Object.id = i;, при этом обработчик у всех один и тот же. А уже внутри обработчика все вытаскивается, поскольку ему передается (Sender : TObject), из которого легко все вытащить как (Sender as TMyButton).id.

В итоге полученное приложение вообще не перекомпилируется для изменения интерфейса. Кнопки появляются так:

0 BUTTON.SHOW
" 2 2 + . " 0 BUTTON.ACTION

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

Что в итоге получается. Большой размер программы, избыточное количество созданных (и спрятанных) виджетов - это минус. Однако все обработчики, TAction, wm_command и прочее уже не имеют смысла - они написаны, скомпилированы, привязаны к обработчикам и уже давно крутятся "под капотом", просто заранее настроены только на запуск кусочков Форта и ждут, пока эти кусочки им назначат. Так что в программе, условно, уже есть 1000 кнопок, 1000 чекбоксов, 100 выпадающих списков и т.д. и т.д. (и одна трехмерная сцена OpenGL).
Сообщение Добавлено: Вт июл 13, 2021 00:45
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Hishnik писал(а):
...

Не для того, что бы "моё слово было последним" :) ! Просто - вдогонку, хотя и говорят, что "не делай добра - не будет зла" ... :)
Обратите внимание ещё на такой класс, как TAction.
Не знаю, есть ли он в Lazarus-е и, если есть, то также он реализован, как в VCL, но в Дельфе он позволяет получать иногда очень красивые и рациональные решения.
Сообщение Добавлено: Пн июл 12, 2021 15:58
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Wlad писал(а):
Делайте, как вам хочется.

Конкретно этот проект я делаю уже полгода. И он не первый в серии, просто он полнее реализует ранее опробованные подходы.

Wlad писал(а):
Ну, если кто-то живёт в какой-то своей, достаточно удивительной, системе смыслов, то и - бог с ним. Можно сколько угодно приводить сравнение в человеко-часах затратности реализации и поддержки тех или иных способов реализации тех или иных архитектурных решений, но вытащить человека из ментальных цепей - самое неблагодарное и безнадёжное занятие!

Это уже элементы НЛП какие-то. Откуда внезапно взялась "удивительная система смыслов" и "ментальные цепи"? Это попросту манипуляция путем введения изначально негативных терминов с целью заставить собеседника оправдываться.

Wlad писал(а):
Можно миллион раз повторить человеку, что НЕЛЬЗЯ реализовывать многозадачность наследуясь от, предлагаемых многими фреймвоками и библиотеками, класса "Поток",

1. Почему вдруг нельзя? Там вообще никаких рекомендаций и пояснений от разработчиков на эту тему нет?
2. Но, собственно, а откуда внезапно взялась многозадачность вкупе с наследованием? Наследование проведено для TButton, а это обычный виджет. Про TThread пока не было ни слова сказано, а он и не унаследован. Просматривается странная логика - раз "нельзя" (почему, кстати?) наследовать TThread, то... нельзя вообще ничего наследовать?
3. Аргументы по поводу кода - другой код. Аргументы по поводу архитектуры - другая архитектура. Когда против архитектуры слова и ссылки в интернет без конкретных цитат - это изначально не эквивалентная позиция.
Сообщение Добавлено: Вс июл 11, 2021 19:03
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Hishnik писал(а):
...
Бррррр.... А - знаете, что? Делайте, как вам хочется.
Лет даже пять назад, я бы продолжил дискуссию, а ля "в интернете кто-то не прав", но, после "дрейфа" по куче фирм, я убедился, что не надо пытаться убеждать в чём-то людей, если это непосредственно не касается моего благосостояния или безопасности. Ну, если кто-то живёт в какой-то своей, достаточно удивительной, системе смыслов, то и - бог с ним. Можно сколько угодно приводить сравнение в человеко-часах затратности реализации и поддержки тех или иных способов реализации тех или иных архитектурных решений, но вытащить человека из ментальных цепей - самое неблагодарное и безнадёжное занятие! Уж лучше сохранить (хотя бы внешнюю видимость) "хороших отношений". Я - просто устал от этого всего. Можно миллион раз повторить человеку, что НЕЛЬЗЯ реализовывать многозадачность наследуясь от, предлагаемых многими фреймвоками и библиотеками, класса "Поток", но если человек упорно не захочет этого понять и "дойти" сам, ПОЧЕМУ это так, то - хоть в лепёшку расшибись, но преодолеть "если так можно сделать, то - так и надо сделать", никаких сил не хватит.
Сообщение Добавлено: Вс июл 11, 2021 18:45
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Wlad писал(а):
зато в тэг влезет указатель на запись/класс, который содержит индекс, строку для запуска на форте, номер Форт ВМ

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

Wlad писал(а):
(или, вообще, - на компонент. этот указатель на комонент вам сослужит ещё очень полезную и интересную службу)

Это который (Sender : TObject) во всех списках параметров? :)

Wlad писал(а):
ну, это - от Вашей задачи и правильности проектирования системы, для решения этой задачи, зависит.

"Зависит от задачи" - это абстрактные слова, которые позволяют дистанцироваться от обсуждения. Система вполне конкретная, такая, какая описана. Добавление кнопки там - это мелкое тактическое решение, и совершенно незачем связывать себя по рукам и ногам изучением связности, правильности и прочего. Программирование для того и нужно, чтобы решать конкретные практические задачи, и предоставляет для этого инструменты из своей области. Если мне показалось удобным запускать некоторое действие нажатием кнопки - значит, попробую добавить кнопку, а инструмент должен мне это добавление сделать простым и удобным. Иначе зачем вообще компьютер? Не для решения же задач, которые он сам и создал.

Wlad писал(а):
Так кнопки и НЕ ДОЛЖНЫ такие поля иметь или иметь к ним какое-то отношение.

"Не должны" не эквивалентно "не могут". Мне удобно связать с элементом интерфейса сразу текст на Форте.

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

А теперь можно внимательно перечитать тему :) Смысл проекта как раз и заключается вот в таком "конфигурационном файле", просто он существенно этот "файл" перерос, а вместо этого Форт управляет в рантайме виджетами GUI, конфигурируя их таким образом, чтобы они при активизации выполняли строки Форта. Соответственно, и код выстраивается под этот процесс.

Wlad писал(а):
Кстати, введением того, упомянутого мной, указателя на компонентв эту запись/класс вы имеете возможность обозначить, кто будет ответственным за удаление этой записи. То есть обозначается "закон владения".


MAXBUTTONS кнопок создается при старте, и удаляются при закрытии программы. Это не специфичная для Форта задача, и подобные вещи убраны внутрь.

Wlad писал(а):
в Вашем случае - ассоциацией, а, вот - чем конкретно - агрегацией или композицией


Ну вот хорошо, что там изложено в терминах is a - has a. Сравниваем фразы.

"Кнопка на форме является кнопкой TButton, которой добавлены поля". (is a button - наследование)
"Кнопка на форме владеет кнопкой TButton и еще несколькими полями". (has a button - ассоциация)

Владеть кнопкой может виджет более высокого уровня - панель с кнопками, окно, группа кнопок. Поэтому ассоциация по сути означает, что видимая кнопка - это вовсе не кнопка, а она владеет какой-то другой кнопкой. И какой смысл в этом?
Сообщение Добавлено: Вс июл 11, 2021 17:07
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Hishnik писал(а):
Wlad писал(а):
В тэге вы можете хранить всё, что угодно.
Вот посмотрел - кнопке добавлен ее индекс, строка для запуска на Форте и номер Форт ВМ, которой это отправлять. В тэг как-то не лезет.
зато в тэг влезет указатель на запись/класс, который содержит индекс, строку для запуска на форте, номер Форт ВМ и, я бы ещё добавил указатель на эту же кнопку (или, вообще, - на компонент. этот указатель на комонент вам сослужит ещё очень полезную и интересную службу) :)
Hishnik писал(а):
Wlad писал(а):
Любое вводимое новое отношение увеличивает связность системы.
Тогда получается, что и кнопку на форме нечего создавать? :)
ну, это - от Вашей задачи и правильности проектирования системы, для решения этой задачи, зависит. :)
Hishnik писал(а):
Wlad писал(а):
"Ещё несколько полей", вы вынуждены вводить (осознанно или нет) - для расширения множества состояний объекта, потому, что предок вас чем-то не удовлетворил. А раз ввели состояния, то переходы в них производятся неким функционалом-реакциями на какие-то внешние воздействия на этот объект. Тут - два случая: либо вы расширяете набор реакций,
Разумеется, расширяется набор реакций. Кнопки по умолчанию не предназначены для запуска текста на Форте и не имеют соответствующих полей.
Так кнопки и НЕ ДОЛЖНЫ такие поля иметь или иметь к ним какое-то отношение. Функционал кнопки - вызов некоего делегата, про который ОНА "ЗНАЕТ", потому, что разработчики этой кнопки сделали это "знание" частью функционала и интерфейса этой кнопки. Но функционалу надо передать контекст. Связующим звеном будет как раз и будет запись или класс, указатель на который помещается в тэг кнопки. Именно для этого тег и был также введён в интерфейс и функционал кнопки. Теперь у вас сущность "кнопка" становится универсальным элементом ТОЛЬКО в понятийном базисе пользовательского интерфейса и ОТДЕЛЯЕТСЯ от КОНКРЕТНОЙ ЗАДАЧИ. Связность системы падает и кусок интерфейса пользователя становится более свободным. Более того, это самое "связующее звено" само становится отдельной сущностью и может быть описано неким идентификатором в, например конфигурационном файле, в котором вы будете описывать взаимосвязь элементов гуи и сущностей ваших задач. :)
Кстати, введением того, упомянутого мной, указателя на компонентв эту запись/класс вы имеете возможность обозначить, кто будет ответственным за удаление этой записи. То есть обозначается "закон владения". :)
Hishnik писал(а):
Wlad писал(а):
Просто мы наследование заменяем агрегацией, ссылаясь на некий реализатор функционала через уже имеющейся элемент.
Конкретно в данном случае - чем заменить наследование?
в Вашем случае - ассоциацией, а, вот - чем конкретно - агрегацией или композицией (https://metanit.com/sharp/patterns/1.2.php) - определите сами, по специфике задачи и как вы её решите.
Сообщение Добавлено: Вс июл 11, 2021 11:10
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Wlad писал(а):
В тэге вы можете хранить всё, что угодно.

Вот посмотрел - кнопке добавлен ее индекс, строка для запуска на Форте и номер Форт ВМ, которой это отправлять. В тэг как-то не лезет.

Wlad писал(а):
Любое вводимое новое отношение увеличивает связность системы.

Тогда получается, что и кнопку на форме нечего создавать? :)

Wlad писал(а):
"Ещё несколько полей", вы вынуждены вводить (осознанно или нет) - для расширения множества состояний объекта, потому, что предок вас чем-то не удовлетворил. А раз ввели состояния, то переходы в них производятся неким функционалом-реакциями на какие-то внешние воздействия на этот объект. Тут - два случая: либо вы расширяете набор реакций,

Разумеется, расширяется набор реакций. Кнопки по умолчанию не предназначены для запуска текста на Форте и не имеют соответствующих полей.

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

Конкретно в данном случае - чем заменить наследование?
Сообщение Добавлено: Сб июл 10, 2021 04:13
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Hishnik писал(а):
Я не увидел конкретных рекомендаций использовать Tag для хранения индекса этого виджета в массиве виджетов. Нужен не "тэг компонента", а "индекс кнопки в массиве указателей на динамически создаваемые объекты". Подобная идея описана в signalMapper из Qt, но он объявлен устаревшим в 5.x.
В тэге вы можете хранить всё, что угодно.
Hishnik писал(а):
Wlad писал(а):
Наследование увеличивает связность частей программы (снижает модульность) и вводит лишние сущности при уже имеющемся (специально выделенном, под такие случаи) средстве.
Ну это скорее теоретически.
Любое вводимое новое отношение увеличивает связность системы. Тем более - на базе "достаточно специфического семантического отношения", с достаточно длинным шлейфом всяко разных "последствиеффЪ" такого решения.
Hishnik писал(а):
Наследование по принципу "такое же, только еще несколько полей" ничего критического не создает.
Э-нет. Не всё так "легко и просто"! :)
"Ещё несколько полей", вы вынуждены вводить (осознанно или нет) - для расширения множества состояний объекта, потому, что предок вас чем-то не удовлетворил. А раз ввели состояния, то переходы в них производятся неким функционалом-реакциями на какие-то внешние воздействия на этот объект. Тут - два случая: либо вы расширяете набор реакций, либо модифицируете имеющийся набор с дополнительными операциями на выходах объекта и над его внутренними элементами составляющими его состояния...
Наследование - не самоцель и не "повторное использование кода". Вообще, наследование лучше как можно реже использовать. Это - достаточно искусственная и притянутая за уши "консепсия" в ООП/А/Д, не имеющая в реальном мире НИКАКОГО изначального механизма или аналогии (в том числе и в биологии :) )
Hishnik писал(а):
К тому же там не только индекс, а еще и строка Форта для выполнения при нажатии.
Да - что угодно. Просто мы наследование заменяем агрегацией, ссылаясь на некий реализатор функционала через уже имеющейся элемент.
Сообщение Добавлено: Сб июл 10, 2021 02:51
  Заголовок сообщения:  Re: Forth + Lazarus IDE  Ответить с цитатой
Я не увидел конкретных рекомендаций использовать Tag для хранения индекса этого виджета в массиве виджетов. Нужен не "тэг компонента", а "индекс кнопки в массиве указателей на динамически создаваемые объекты". Подобная идея описана в signalMapper из Qt, но он объявлен устаревшим в 5.x.

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

Ну это скорее теоретически. Наследование по принципу "такое же, только еще несколько полей" ничего критического не создает. К тому же там не только индекс, а еще и строка Форта для выполнения при нажатии.
Сообщение Добавлено: Чт июл 08, 2021 22:09

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB