Вверх ↑
Этот топик читают: Гость
Администрация
Ответов: 15294
Рейтинг: 1515
#76: 2008-06-09 16:05:39 ЛС | профиль | цитата
nesco писал(а):
А можно поинтересоваться -- в каком пункте это реализовано и как

Это св-во определенное в ECreator как data_element - в качестве списка значений задаются классы элементов, которые могут быть присвоены данному св-ву. В среде автоматически строится список имен доступных на схеме элементов, и выводится в качестве выпадающего листа в редакторе св-тв. В кодогенераторах ссылку на элемент, присвоенный данному св-ву data_element можно получить по propGetLinkedElement(). Единственная особенность использования - у линкуемых элементов обязано присутсвовать св-во типа data_str с именем Name. Иначе среда выдаст ошибку.

PS: для занимающихся проблемами наследования предлагаю попутно еще подумать на тему того, как интерфейсно наследовать элементы классов DPElement и DPLElement.
карма: 26
0
Ответов: 16884
Рейтинг: 1237
#77: 2008-06-09 16:11:59 ЛС | профиль | цитата
Dilma писал(а):
См. ECreator в последних обновлениях.
nesco,Если работаешь в англ. интерфейсе, то лучше не запускать.
карма: 24
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 3655
Рейтинг: 69
#78: 2008-06-09 16:27:20 ЛС | профиль | цитата
Galkov писал(а):
надо видео какое-то

Для программиста всё остаётся как и было он видит два одинаковых
мультика(только знает что данный тип мультика компилируется один
раз).Собственно он для этого его и ставил.
И кодогенератор это тоже знает.
карма: 0

0
Ответов: 2125
Рейтинг: 159
#79: 2008-06-09 18:49:27 ЛС | профиль | цитата
Galkov писал(а):
Собственно, я ждал каверзных вопросов от коллеги tsdima, который такие вещи сечет на раз
Все это (указатель на объект) похоже на ##hselect для чужого экземпляра.

Когда-то, когда я был "такой же User, как и мы все" и только начинал разбираться со всеми этими мультиками и ссылками на мультики, помнится я выдвигал идею о том, что коллекция однотипных мультиков должна быть общей, и можно было бы получить handle от одного мультика, и воспользоваться им в ##hselect другого, который является ссылкой на мультик. Мы тогда на пару с AlexKir пытались продвинуть ООП в HiAsm, но из этого так ничего и не вышло.
карма: 1

0
Разработчик
Ответов: 25681
Рейтинг: 2087
#80: 2008-06-09 19:04:36 ЛС | профиль | цитата
tsdima писал(а):
но из этого так ничего и не вышло

Можно глупый вопрос -- а почему
карма: 20

0
Администрация
Ответов: 15294
Рейтинг: 1515
#81: 2008-06-09 19:07:56 ЛС | профиль | цитата
По-моему такие вещи лучше делать в соответсвие с канонами классического ООП, когда есть описание класса и есть экземпляр класса. Это два разных элемента с разной функциональностью и назначением. А не мультик и ссылка на него...
карма: 26
0
Ответов: 9906
Рейтинг: 351
#82: 2008-06-10 00:47:39 ЛС | профиль | цитата
tsdima писал(а):
Мы тогда на пару с AlexKir пытались продвинуть ООП в HiAsm, но из этого так ничего и не вышло

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

  • Dilma первым делом тогда сообщил, что просто поинтеры, это - читы во всех высокоорганизованных языках программирования, и что боцман (к примеру) за такое бил сразу же канделябрами по голове. В чем я с ним был согласен тогда, и согласен сейчас.
  • НЕ читами является примерно такое
    
    #pas
    function(obj:TMulti)
    begin
    ....
    obj.doMethod(да мало ли чего тут);
    ....
    end;
    Внимание, это не просто левый поинтер, а указатель на конкретный класс, и среда отслеживает, чтобы он таковым являлся. Что значит таковым - при вызове мы имеем право туда подставить и другой класс, но он обязан быть наследником исходного.
    Т.е., чтобы это делать необходимо навести порядок с отношениями наследования.
    ВСЕНЕПРЕМЕННО
    Ну я так и сейчас говорю
    Galkov писал(а):
    Просто надо один раз договориться о самосогласованном решении, вот и все...
    Столь подробно я не стал тогда этого объяснять AlexKir, потому-что не очень рассчитывал на успех (если уж на чистоту), а тебе не стал, потому-что ты это лучше меня знаешь

  • А теперь давай вспоминай, кажется AlexKir сообщал, что попробовал снять "защиту" с метода ##hselect (или его научил кто - точно не припомню уже...) и радостно сообщал, что все работает (типа - УРА). Одна незадача (с печалью он сообщал) - выходные события происходят на оригинале.
    Ну, блин, не стал я его посвящать в искусство подмены EditMultiEx.FParent
    Скажем потому, что еще сам не понимал, как правильно (+ вышесказанное)

    Ну а теперь у меня с этим есть определенность, и аналоги из "классики"
    Давай посмотрим, что есть такое точки в нашем элементе в этой самой "классике"
    Левые и нижние - это методы.
    Правые и верхние - это виртуальные ф-ии. Причем, если не назначены, значит абстрактные.
    А подключение связи, это создание объекта наследника, только с переопределением этих виртуалов такими методами, которые вызывают другие методы других объектов.
    В общем, как-то так...
    И тут есть маленькая тонкость, приводящая к большим последствиям, как мне кажется
    Эти абстрактные виртуалы могут лежать как в private, так и в public
    Если мы только наследуем, то нам по барабану, мы можем переопределить любой
    А если занимаемся объекто-указанием, то нам доступны только public
    Может все это несколько коряво а только по смыслу должно быть верно

    Ну скажем есть у нас адаптированный к нам класс TStream - он еще не знает, кто он такой (File или Memory), у него в секции private есть всякие виртуальные методы (Read, Write, Seek, и т.п.) которые будут переопределены конкретными наследниками.
    А то, что он к нам адаптирован, означает, что к него есть в секции public абстрактный метод onRead, который переопределится при создании схемы...
    Ну и что такое элемент DataToFile
    Это оболочка над указателем на этот, адаптированный к нам класс TStream.
    Ну, грубо говоря, не видим мы точек из секции private...
    И получается, что событие onRead должно возникать на элементе указателе, а события "Read, Write, Seek, и т.п." - на элементе оригинале
    Причем, не забудем, что назначаем-то элементу указателю конкретный объект, и вовсе не класса адаптированного TStream, а какого-то из его наследников - MemoryStream, или FileStream. А они отличаются от предка как раз тем, что злополучные точки "Read, Write, Seek, и т.п." у них как раз уже подключены.
    И получается, что то, что эти события срабатывают в оригинале - совершенно правильно, так все в "классике" и происходит...


    Ну ладно, это все слишком умно и непонятно. А может, и не совсем строго
    И фиг с ним... Но у нас в HiAsm все эти сложности могут иметь прямую аналогию, которая нам гораздо понятнее, и достигает того же результата

    Давайте посмотрим...
    Скажем, мы СОЗДАЕМ элемент, используя фичу data_element, опубликованную Dilma
    Фактически мы в этом св-ве (пусть, скажем, называется class) установим TMulti, из вышестоящей демки...
    Когда устанавливаем, то:
    Dilma писал(а):
    список имен доступных на схеме элементов, выводится в качестве выпадающего листа в редакторе св-тв
    Вот теперь, исходя из всего вышесказанного, такое предложение:
    После выбора конкретного элемента (класса TMulti) должен появиться список точек этого элемента с чеками, и пользователю предлагается оптичить необходимые точки (грубо говоря, ну зачем мне все 150 точек от элемента коллеги nesco)
    И главный результат: события на тех точках, которые появились на элементе - в оригинал не пойдут, а будут здесь, у нас. А остальные - пойдут именно в оригинал.
    Вроде по-понятней и наглядней, чем всякие public/private, а результат тот же самый

    Ну и у этого элемента должна точка ##obj, может быть (а может быть и нет...) и одноименное св-во того же типа, но только при установке которого лист следует делать (если делать...) не из классов, а конкретных элементов....
    И тут уже - никаких оптичиваний...
    Хорошо бы чтобы не просто полный лист элементов, а тех, которые являются наследниками св-ва class
    Но возможно, такое навороченное св-во obj - это пижонство...
    Вполне можно обойтись верхней точкой ##obj и потоком
    Мне так кажется... посмотреть осталось

  • карма: 9

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1515
    #83: 2008-06-10 11:00:14 ЛС | профиль | цитата
    примеров не хватает: что есть, почему этого не достаточно и как было бы, будь оно реализовано... Из примера в несколько постов выше проблема не совсем четко прослеживается.

    Galkov писал(а):
    Левые и нижние - это методы.
    Правые и верхние - это виртуальные ф-ии. Причем, если не назначены, значит абстрактные.

    если речь идет о концепции, а не о конкретном пакете, то указанные точки могут трактоваться как:
    левые и правые - последовательность выполнения команд
    верхние и нижние - приемники и источники данных соответственно

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

    Теперь попробуем представить себе пакет для HiAsm, который называется MyINI и у которого есть проект "INI file", как несложно догадаться - генерирующий по схеме ини файл. Что такое понятие "метод", "событие", "объект" или определение "абстрактный" в рамках палитры данного пакета? Или другой вопрос: что есть элемент GetIndexData в данном пакете, наличие которого по заявлениям из предыдущих постов не должено никак зависить от концепции пакета?

    Дабы не возникало таких вопросов и дальше предлагаю сформировать примеры и описать требования, которым должен удовлетворять пакет и целевой язык им генерируемый.
    карма: 26
    0
    Ответов: 9906
    Рейтинг: 351
    #84: 2008-06-10 14:36:24 ЛС | профиль | цитата
    Dilma писал(а):
    Теперь попробуем представить себе пакет для HiAsm, который называется MyINI и у которого есть проект "INI file", как несложно догадаться - генерирующий по схеме ини файл. Что такое понятие "метод", "событие", "объект" или определение "абстрактный" в рамках палитры данного пакета?

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

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

    Но как бы хотелось поговорить о задаче создания программного продукта....
    Ну и какая это задача.
    С одной стороны пользователь представляет информацию в нашем графическом виде, с другой стороны получает продукт
    И думается мне, что здесь очень важно (если вообще не САМОЕ ГЛАВНОЕ) чтобы пользователь абсолютно точно понимал, к чему приведет то или иное действие в схеме
    Т.е., мы ему должны дать точную модель происходящего (ну не знаю как лучше сказать), чтобы он мог делать адекватные выводы
    И это самая главная печка, от которой надо плясать.
    Мне так кажется, иначе, как бы, не очень понятно для кого все это делается

    У нас есть опыт создания такой модели. Ничего лучше (и, кстати говоря - ТОЧНЕЕ), "модели паровозиков" не получилось.
    То, что это аккуратно не изложено на wiki, нет видео к ней, нет исполнения этой модели в "благородных терминах" - это наша беда.
    Это надо просто делать, скажем тем, кто это умеет, или как-то вместе
    И, видимо, с наличия такой модели следует начинать концепцию
    Пока, что думалось, что "создание программного продукта" должно этому удовлетворять.
    И элемент GetIndexData совершенно не противоречит этой модели

    Собственно, ничему не противоречило бы утверждение, что пакет QT выполнен в некой другой модели, кардинально отличной от "модели паровозиков"
    Да, как говорится, кто же против-то....
    Просто пара замечаний:
  • А кто об этом знает (ну пусть мы с тобой - не считаемся)
  • Интересно услышать ее... хотя и не обязательно... но интерсен был бы сам стиль изложения Вот и все...

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

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

    Дык я не против же примеры предоставлять....
    Вот только вопрос (кажется) не очень понял...

    Ну может так, понятней про цели будет...
    Я говорю о создании технологии, которая позволит превратить "зашифрованный" пример коллеги nesco типа ElementsdelphiExampleFormsTreeView_As_DirView.sha -- в нечто читаемое
    Примерно таким образом:
  • Погружаем элемент TreeView в контейнер-наследователь (хотя это все еще не обговорено до конца), который имеет нижнюю точку ##handle
  • Разбиваем схему на отдельные независимые логические фрагменты, демонстрирующие каждый по отдельности свою фишку сего продвинутого элемента.
  • При этом, мы НЕ начинаем пляски с бубном вокруг этого элемента, а для обращения к нему используем элемент Pointer, который уже ненавязчиво связан только одной своей верхней точкой ##obj с вышеупомянутой точкой ##handle
  • Есть гипотеза, что при такой схемотехнике элементы - LineBreakEx исчезнут из схемы за ненадобностью..
    Ну, как бы, цель предлагаемого мной обсуждения -- и есть выработка (придумывание - попросту) таких интерфейсных решений, чтобы эта гипотеза превратилась в великую сермяжную правду.
    Вообще-то - не только.... Но это уж - как минимум
  • карма: 9

    0
    Разработчик
    Ответов: 25681
    Рейтинг: 2087
    #85: 2008-06-10 14:55:24 ЛС | профиль | цитата
    Galkov писал(а):
    "зашифрованный" пример


    Применил на свою голову NewTechnologys, посчитал, что без линков читаться будет проще, а оно вон как вышло -- "зашифровал" получается.
    карма: 20

    0
    Ответов: 9906
    Рейтинг: 351
    #86: 2008-06-10 15:10:28 ЛС | профиль | цитата
    А я то чего Этот термин Dilma первый применил
    ------------ Дoбавленo:

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

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

    Примерно в таком стиле я и пытался делать, но помещал это в контейнер-helper - коды этих контейнеров мы же не строим
    Первый раз nesco огорчался на такое на примере SpriteDemo из "Этюдов". Шибко огорчался
    Ну там я вытянул из контейнера, фиг с ними с созданными не в тему элементами... Демка же...
    И возникло у меня подозрение, что среда терпит линки только в пределах "прямой видимости" по дереву объектов, а расположение оригинала и линка на соседних ветках этого дерева - болт с гайкою...

    Так собственно, в примере, здесь выложенном - у меня вообще никаких вариантов не было...
    Есть TAB, в двух его соответствующих панелях - две одинаковые схемы (тоже панели, кстати, и входить из них в редактор форм - занятие не для слабонервных).... Одна (это сегодня так) оригинал, вторая линк на него - вроде бы и вариантов нет

    И еще, в том примере очень модно было в свои мультики иконки с #main вешать... Чтобы их было какое-то разумное число, многие из элементов Icon являлись линком на другой, аналогичный
    Наверное, это тоже смертельно...
    ------------ Дoбавленo:

    Ну ладно, хватит пока - рука бойцов колоть устала
    карма: 9

    0
    Ответов: 2125
    Рейтинг: 159
    #87: 2008-06-10 15:30:52 ЛС | профиль | цитата
    Galkov писал(а):
    Левые и нижние - это методы.
    Правые и верхние - это виртуальные ф-ии. Причем, если не назначены, значит абстрактные.

    Скорее не виртуальные функции, а делегаты (новое модное слово)

    Давай теперь я расскажу, что я думаю о текущей концепции ХиАсм.
    Можно рассмотреть эту концепцию с разных точек зрения.

    Итак. С точки зрения построения программы.

    Есть две сущности: процедуры и функции. И то, и другое, можно либо использовать, либо реализовывать.
    Комбинация всего этого даёт нам как раз четыре возможные точки:
    реализация процедуры (левая)
    реализация функции (нижняя)
    использование процедуры (правая)
    использование фукции (верхняя)

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

    Теперь с точки зрения данных.

    Есть две сущности: клиент и сервер. А есть два направления данных: передача и приём.
    Комбинация всего этого даёт нам опять четыре возможные точки.

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

    Galkov писал(а):
    а для обращения к нему используем элемент Pointer

    Возможно, это могло бы решить проблему реализации и использования интерфейса, но как среда определит, на какой мультик ссылается этот Pointer? Ведь от этого должен зависеть набор точек у этого компонента. Предложение использовать ссылку на мультик уже несколько раз отвергалось. В конце-концов, один объект может предоставлять несколько интерфейсов, как быть в этом случае?

    карма: 1

    0
    Разработчик
    Ответов: 25681
    Рейтинг: 2087
    #88: 2008-06-10 15:48:48 ЛС | профиль | цитата
    tsdima писал(а):
    но как среда определит, на какой мультик ссылается этот Pointer

    А если использовать виртуальные списки этих Pointer'ов
    карма: 20

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1515
    #89: 2008-06-10 16:40:26 ЛС | профиль | цитата
    Про пользовательские конструкторы данных я уже как раз думал. Особенно когда надо упаковать их в массив, как в примере по OpenGL из пакета QT, где пришлось использовать три отдельных массива для хранения координат x, y и z одного и того же объекта. Это мягко говоря кривое решение задачи...

    Вот как бы хотелось решить туже задачу с использование "шаблона типа":

    1) делаем некий элемент с именем record(он является контейнером, но без возможности добавления точек)
    2) делаем кучу элементов с именами FieldInteger, FieldString, FieldReal и т.д.
    3) положим нам нужен тип данных, состоящий из одного целочисленного поля и двух строковых - делаем:
    
    #sha
    Add(MultiElementEx,13963480,105,196)
    {
    }
    BEGIN_SDK
    Add(EditMultiEx,8914275,21,21)
    {
    VarCount=#6:record|
    }
    Add(Memory,3004996,112,49)
    {
    Default=Integer(0)
    }
    Add(Memory,9579031,112,98)
    {
    Default=String()
    }
    Add(Memory,5139641,112,147)
    {
    Default=String()
    }
    END_SDK

    тут Контейнер это наш гипотетический элемент Record, а элементы Memory внутри - это поля, указанные выше. Точка "record" это готовый шаблон структуры
    4) далее создаем элемент с каким-нибудь названием TemplateArray
    
    #sha
    Add(MultiElementEx,5229834,105,245)
    {
    }
    BEGIN_SDK
    Add(EditMultiEx,9259894,21,21)
    {
    VarCount=#5:array|
    DataCount=#4:type|
    }
    END_SDK
    где точка type - это шаблон данных, array - это массив, сконструированный по шаблону
    5) ну и наконец допишем наши элементики для работы с массивами так, чтобы они понимали не только простейшие данные(как сейчас), но и такие, которые пользователь сделал с использованием среды. Причем запись/чтение можно производить, например, через МТ

    Вот и получаем нехитрую схемку, которая добавляет число и две строки в наш пользовательский массив:
    code_9251.txt

    расширяя идею дальше, можно вставлять в элемент record скажем элементы типа ToInteger, ToString и т.д., которые по событию onConvert переведут все поля структуры в требуемый тип данных и вернут результат методом doReturn, т.е. получим полноценный тип данных.

    К сожалнию минус у подхода только один: как реализовать это на базе стандартного пакета большой и толстый вопрос. Скорей всего никак...

    ------------ Дoбавленo:


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

    ------------ Дoбавленo:


    глядя на схему подумалось, что связывать через точку шаблон с элементом, который по этому шаблону строит данные не совсем верно. Тут видимо правильнее связать их через data_element, чтобы дать пользователю наглядное понимание того, что шаблон не делает в схеме абсолютно ничего и работает только на этапе кодогенерации.

    ------------ Дoбавленo:


    вот такой код должен при этом получиться:
    
    #cpp
    // элемент record
    typedef struct {
    int field1;
    string field2;
    string field3;
    } TRecord1;

    .....
    // элемент TemplateArray
    TRecord1 *arr;

    .....
    // элемент ArrayWrite
    arr[0].field1 = mt1;
    arr[0].field2 = mt2;
    arr[0].field3 = mt3;
    .....
    карма: 26
    0
    файлы: 1code_9251.txt [922B] [231]
    Ответов: 2125
    Рейтинг: 159
    #90: 2008-06-10 17:02:13 ЛС | профиль | цитата
    Dilma писал(а):
    ну и наконец допишем наши элементики для работы с массивами так, чтобы они понимали не только простейшие данные(как сейчас), но и такие, которые пользователь сделал с использованием среды

    А про порядок следования элементов в записи и в МТ-потоке ты почему-то умолчал.

    Насчёт использования и реализации интерфейсов: в голову приходит только нечто вроде компонента "Кабель", только для всех 4 видов точек одновременно.

    А как это должен учитывать CodeGen (чтобы генерировать нормальные интерфейсы) - вообще непонятно.

    Кстати, LineBreakEx очень похож на простейший интерфейс с одним методом

    Я бы даже сказал, он мог бы служить для определения интерфейса внутри мультика.
    карма: 1

    0
    Сообщение
    ...
    Прикрепленные файлы
    (файлы не залиты)