Редактировалось 2 раз(а), последний 2017-06-14 22:25:11

планирую, но тут есть варианты


будет


Буду рассматривать


возможно

---

А вообще, пока я не ушёл слишком далеко, решил реализовать наработки в Qt, и собственно посмотреть основные преимущества и недостатки оного относительно Lazarus на "рабочем" варианте, так сказать
Ведь гораздо удобней реализовать десктопную и мобильную версию, использую один инструмент, если оный позволяет это (естественно будут разные проекты).

Уважаемые коллеги.
Обещать-то я -- обещал, выложить свои соображения. Да чего-то как-то неожиданно долго это получается.

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

Сильного взрыва не ощутил, но в упор не нашел ни слова про рекурсивность интерфейса, камень предкновения, кстати, у нас сейчас в обычном пакете

Подробней пожалуйста.
Если решение рекурсивной задачи - тогда легко расскажу. Созданием динамических объектов.
Если про кольцевание - не дописал еще. Его тупо не должно быть. И среда должна контролировать это дело - и не пущать.

В принципе, это и есть рекурсивность интерфейса.
Пойдем дальше -- имеем рекурсивную задачу, которая будет иметь N-е количество обращений к самой себе, но памяти будет занимать, как один объект. При создании динамических объектов, как предполагается осуществить такое взаимодействие? Это получится N-е количество объектов или как-то иначе? Те как предполагается решить такую задачу на уровне графического интерфейса?

В принципе, это не рекурсивность интерфейса, а павлино-утко-еж

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

Чем достигается корректность рекурсии в структурном программировании. Тем, что функция работает только с памятью, которая расположена в стеке: аргументы и локальные переменные. Ровно в тот момент, когда локальную переменную сделают глобальной - все это может легко перестать работать.
Так вот: в классической рекурсии на каждом уровне выделяется новая память. В стеке - это побыстрее, конечно же, чем в хипе, но - обязательно ВЫДЕЛЯЕТСЯ.

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

Ну вот, либо так, либо как у функциональщиков - думать "задом наперед"
Мне больше нравится - ТАК.

Какой из этого вывод: мы не можем, вообще-то говоря - потребовать реентерабельности методов объекта. Это просто противоречит нашей концепции. Следовательно, кольцевание - это табу.
Но, рекурсивные задачи никуда не исчезли, умеем ли мы решать таковые в концепции ООП.
Умеем. Созданием динамического объекта, вызовом нужных его методов, с последующим уничтожением.

nesco, можешь себе представить, я это пробовал. Здесь на форуме.
Когда-то, когда "линки" только появились, Dilma разрешал их рекурсивное использование. И я тут же попробовал сортировку массива.
Идея была такая: получивши массив с верхней точки, я создавал два других (вдвое меньшей длины) запускал (сортировал) два мультика (это и были рекурсивные линки на самого себя)в режиме OnlyOnce, и из этих двух отсортированных половинок - перезаписывал входной (который я с самого начала взял с верхней точки).

Да, можешь себе представить, на каждом уровне рекурсии (а таковых LOG(N)) аллоцируется память. Так она и в классическом структурном программировании аллоцировалась.

Где-то на форуме была схема. И она работала: асимптотика была N*LOG(N).
Да, для учета эдаких рекурсий пришлось модифицировать кодогенератор. И я это сделал. Успел
А вот Dilma проблему с линками так и не разрулил. И просто запретил рекурсивные линки. На долгие времена.

Хотя, у меня есть подозрение, что сейчас они снова разрешены... Но руку на отсечение не дам.

Я понял задумку, но как сие отразится на быстродействии всего алгоритма

nesco, мухи отдельно - котлеты отдельно

Это реально вторая часть задачи.
Не, не потому, что я не хочу ее решать. Хочу, но говорю: "Огласите весь список, пжалуйса"

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

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

Вообще-то "будет" - не то слово. Я ее уже слышал.
------------ Дoбавленo в 13.17:

А он нафиг не нужен. ((Бритва Оккама: не вводи новые сущности без необходимости))
Предполагается возможность набивать в массив ObjectArray (предполагаемый базовый элемент) любые элементы (в смысле - указатели на них). В том числе, и никак не связанные отношениями родства.
Главное что бы их динамический интерфейс являлся наследником статического, указанного в свойстве <Class> этого массива.

Посмотрел. На мой взгляд - очередная попытка сделать из HiAsm "объектный HiAsm". Говоря, что каждый компонент есть объект, мы делаем шаг в сторону от эффективной кодогенерации. Возьмём к примеру описанный в данном документе VirtualObject и задумаемся о его реализации. Реализация левых точек вполне логично превратится в вызовы методов объекта, которым передаются данные из потока. Но поскольку эти методы должны активировать верхние и правые точки именно этого VirtualObject, методам должен передаваться ещё и указатель на интерфейс, представляющий из себя набор верхних и правых точек данного VirtualObject. В результате - одни виртуальные вызовы CALL и ни одной inline подстановки.

Мне кажется, нужно разделить компоненты на компоненты-объекты, позволяющие выделять сущности, и компоненты-не-объекты, позволяющие делать эффективный код посредством inline. Хаб, как элементарный компонент - типичный пример компонента-не-объекта, который просто обязан быть inline. Указатель на него вообще не имеет смысла. Это просто последовательность действий с одинаковым аргументом.

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

Согласен. Три раза.
И я себе все отлично представляю. И виртуальность не только клиентских, но и серверных точек (в тот момент, когда они появились на Self-е).

Я даже для себя закон вывел: чем удобнее для пользователя, тем хуже эффективность.
В голове у меня это сидит так: слева - интерфейс пользователя, справа - выходное качество.
И есть две вертикальные границы.
Чем левее левая - тем лучше пользователю. Чем правее правая - тем лучше код.
Что между этими границами - искусственный интеллект, заложенный авторами кодогенератора/компилятора.

Ассемблер - расстояние между этими границами небольшое, и они обе очень даже справа.
Если мы сдвинем левую границу влево, не добавляя интеллекта, с выходным качеством будут реальные проблемы.

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

Изложенное прочитал. Это именно то, что я ожидал услышать. Необходимость некоторых вещей я тоже ощутил: ограничение количества типов данных, циркулирующих по связях; необходимость динамического создания объектов (точки doCreate, doDelete).

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

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

Ещё хотел сказать по поводу наследования. Когда мы помещаем компонент в контейнер, мы получаем агрегирование. В классическом ООП объект, находящийся внутри другого получает своё имя и не виден снаружи. Замечу, однако, что разница с наследованием не очень большая. При наследовании он не получает собственного имени, все его публичные методы автоматически видны снаружи и для обращения к нему изнутри не нужно ссылаться на него по имени (ну разве что в случае, когда метод перекрыт в наследнике, мы пишем inherited или имя родительского класса). Т.е. в HiAsm можно поступить аналогично: помещаем любой компонент в контейнер и объявляем его родителем. Можно и множественное наследование таким образом разрешить. Т.е. объявление родителем приводит лишь к тому, что интерфейс родителя становится виден снаружи.