Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2008-06-08 21:57:49 ЛС | профиль | цитата
Уважаемые коллеги, мне представляется, что не том вы говорите.
И уж точно - не в том стиле.

У меня есть совершенно конкретное предложение: давайте поговорим на тему, которую можно назвать "спецификация языка программирования HIASM"
Естественно, давайте говорить не с чистого листа, а опираться на то, что мы сегодня имеем
Придумывать необходимые интерфейсные решения совместно.

Ну есть у меня какие-то соображения на этот предмет...
Но они не являются законченными, например из-за того, что сомневаюсь что именно так (как именно мне приперло в голову) будет понятно всем.
"Будет понятно" - именно в том смысле, что будут помогать думать над алгоритмом, а не создавать дополнительные заморочки для пользователя
Вот так я предлагаю...
Причем, наш разговор должен быть именно интерфейсным
Никакого отношения к конкретному пакету, какому-то компилятору, какой-то библиотеке
Хотелось бы, что бы результатом нашего рассуждения была фраза такого типа: "Вот такую задачу программисту на HiAsm удобней решать именно так: <описание>"

Ну а результаты нашего обсуждения (это самое <описание>) давайте изложим именно по "форме", предложенной Dilma.
Даже неделя труда по описанию этих всех "винтиков", это НИЧТО, по сравнении со временем, уже потраченным безрезультатно.



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

Не моя фраза, но не вызывающая ни малейших сомнений: 90% успеха работы программиста, это правильно созданные типы данных
Что такое структура данных в HiAsm
Да просто мультик, в котором мы помещаем эти данные: Memory, MemoryStream, Bitmap, да и другие мультики...
И можем нарисовать кучу необходимых методов.
Пока все в порядке.
А теперь давайте вспомним, что такие данные формируются не всегда, чтобы использовать это дело в одном экземпляре
Что мы можем использовать в нескольких экземплярах
Правильно, элемент.
И чего получается, в конкретной задаче мы формируем конкретный именно для этой задачи класс данных, и вынуждены запускать ECreator, помещать его в палитру элементов
Не слишком ли много суеты для простейшего действия
И что, для следующего проекта перестраивать палитру элементов в HiAsm

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

Получается что у нас должно быть два совершенно разных типа некого "линка": новый экземпляр того же класса, что и в оригинале, и указатель на некий конкретный экземпляр
А мы что имеем...
Имеющийся у нас линк обладает теми же самыми св-вами что и оригинал, а это характерно как раз для указателя
У нас графически отличаются линки от оригинала, что было бы совершенно логично именно для указателей - если это разные объекты одного класса, то они по жизни совершенно равноправны. Разве можно сказать про несколько элеменов MemoryStream, что один из них оригинал, а остальные - линки на него...
Но линк у нас это совсем не указатель, это именно новый экземпляр класса объекта-оригинала. По крайней мере в пакете Дельфи
Так сделано давно...
Так получилось....
И "так" будет и дальше получаться, если мы не определимся до построения, чего строить-то хотим: самолет или подводную лодку

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

Ну и, получивши звание теоретика, я приведу пример из конкретной практической схемы...
Могу и выложить (хоть и большая), проблем нет. Но для затравки - на словах
У меня есть некий программатор.
У него есть разные табы: FUSE, FLASH, EEPROM, LOCK, Test
На вкладках FLASH и EEPROM тот кусок который выполняет чтение из камня - ну совершенно одинаковые, даже координаты визуальных контроллов совпадают
За исключением одного (в смысле - двух разных) мультика, у которого одна левая точка - doRead, и три правых - onSend, onResult, onStop
Точки-то одинаковые, а работают по разному - даже разным количеством выходных событий плюются, в ответ на входное

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

Вот есть такая совершенно практическая потребность...
Повторю вопрос, коллеги: "Как должен поступать программист HiAsm, встретивши такое "
высказывайтесь
карма: 9

0