СЧ> Я не совсем понял что есть «процедура обработки» и что она не обрабатывает?
«Процедура обработки» для View, как и для QUEUE кстати, это практически тот-же драйвер в терминологии FILE. Т.е. при инициализации обьекта типа View или Queue Кларой создается заголовок для них, строится описание их внутренней структуры и в заголовок записывается адрес точки входа в процедуру обработки. Для Class, вероятно, так-же. Еще не смотрел. Для всех однотипных конструкций — одна и та-же процедура обработки.
Дальнейшие действия с такими конструкциями проходят так:
- при использовании PROP:xxxx код этого пропа (из Property.clw) вместе с указателем на заголовок структуры передается внутренней процедурке-пускачу, которая напрямую передает управление той самой «процедуре обработки», адрес которой выбирается из заголовка структуры.
- при использовании стандартных операторов типа Open(View), Get() и тому подобных, они получают адрес заголовка структуры. После необходимых подготовительных действий эти процедуры опять-же вызывают процедуру-пускач, которая передает управление «процедуре управления».
Т.е. реально с данными конструкциями работает именно эта самая «процедура обработки». Вообщем, как видишь — полная аналогия с файловыми драйверами.
Таким образом, зная полный протокол вызовов «процедур обработки», как это имеет место быть в случае с файловыми драйверами, можно самому писать драйвера для таких конструкций, что сделает ненужным перегрузки стандартных процедур типа Open/Get и т.п.
СЧ> ??? Тогда я не очень понимаю методологию твоей работы с классами. Если тебе объекты нужны только по требованию, то используй ссылки и NEW(), DISPOSE(). Четыре байта — меньше некуда!
Да привык я как-то, прямо описывать в секции данных такие классы:)
Ну, да ладно — уговорил!:)
Тогда схема работы будет такая:
Construct() - hide
Если по ходу работы возникнет необходимость переинициализации обьекта, например для описания новой структуры, то:
Kill() - иначе не сработает Init() Init()
... описание структуры ... Kill() - при необходимости (все равно сработает Destruct()) Destruct() - hide
Кстати, решил не выносить в отдельный метод «загрузку описания структуры из текста». Теперь это можно будет сделать сразу вместе с Init(ViewDesc). При этом:
- если обьект уже создан по Construct(), то просто формируется новая его структура.
- если обьект уже был сконструирован, то происходит принудительная деинициализация с повторным созданием нового обьекта.
- если обьект был убит методом Kill(), то создается новый.
СЧ> Я уже говорил, посоветую еще раз: сделай класс по созданию структуры, ну и если уж так хочется сделай еще класс-наследник и пихай туда что хочешь. Так будет правильнее. Хм, если верить умным статьям, то 1 класс это мало 10 много, оптимально 4-5 в цепочке наследуемых…
Не люблю городить кучу маленьких, отдельно никому не нужных, классов! Я понимаю, если делать класс, который делает вещи, нужные во многих случаях. Типа, например, класс DynaGroup. Он генерит новую динамическую группу, что всегда нужно классам типа DynaQueue/DynaClass/DynaFile. А в случае с View, мне кажется, это лишнее. По своей сути View — структура, которая не имеет абсолютно ничего общего с остальными структурами Кларион. Кроме, пожалуй, своего заголовка.
Да и потом — не нужны некоторые методы из базового класса — не используй! Но, зато, если вдруг понадобятся — всегда под рукой, не надо писать дополнительный класс.
P.S. А умные статьи… Ну, что поделаешь, если некоторые только и умеют что статьи писать с абстрактными примерами, написанными на абстрактных языках для абстрактных компьютеров. Кушать всем хочется!
Вот только честно! Кто из нас в практических приложениях использует хоть часть из того великого множества «умных советов/правил», которыми просто напичканы все журналы и книги по программированию?!
Я не имею ввиду стандартные правила типа осмысленных имен переменных и структур, их однотипного использования и пр.
Теории, конечно нужны! Но, в основном, для создания более функциональных инструментов программирования. Типа быстрых и мощных СУБД, разных CASE-технологий и пр.
В реальных приложениях, обрабатывающих реальные данные, большинство из таких теоретических советов/правил просто неприменимы! Я думаю — к счастью! Иначе, все программирование выродилось бы в простое кодирование с четкими и ясными советами/правилами — приказами, как надо строить то или иное приложение! Ну так это может делать прекрасно и машина! Зачем тогда программисты?!
Кто-нибудь знает хоть один универсальный комплекс по написанию реальных приложений? А ведь, если взять во внимание все то обилие правил/советов, то уже давно было бы пора появиться такому «спасителю юзера»!
Чем плохо — захотелось, скажем, юзеру программку по планированию оптимального графика «почесывания левой пятки» в зависимости от внешних условий — дал задание такому «программисту» и через несколько секунд — получи готовенькую, с пылу-жару программку!
Пардон! Увлекся малость 🙂