В принципе, я и имел в виду типы, под которые выделяется память. Тот же string -- это же массив символов переменной длины, под него, просто необходимо выделить участок памяти; под любую переменну, определяющую структуру, как тип record, тоже нужно выделить память и тп

Да, например таблица, как в sqlite code_15834.txt

---

Да, так я понял добавление Type возможно только в пакет FTCG, а на пакет Windows рассчитывать нельзя?

Assasin, ошибка компиляции модуля ShareMyType.pas
под D6:
"ShareMyType.pas(72) Error: Declaration of 'Data_Get' differs from previous declaration"

Перезалито, а так же исправлено несколько недочетов в некоторых компонентах, Minkovsky, сейчас попробуй, должно заработать

добавление возможно везде - вечь шла только о целесообразности таких элементов в рамках существующих технологий.

Под "возможно" я имел ввиду целесообразно, просто из постов выше я до сих пор не пойму куда целесообразно добавить Type

Теперь компоненты доступны по SVN

в wiki адрес svn нужно поменять

Добавил на svn новый компонент Type_MultiData(похож с MT_MultiData)
Добавил информацию в отладку, теперь схемы с Type можно отладывать и в окне Debug(2) будет показана информация о нем в следующей структуре Name: "<имя>" Items: {"<переменная>": <значение>}{...}{...}...
Компоненты проверены и полностью рабочие.
Так же добавлена информация о компонентах в WIKI, ее можно найти по адресу HiAsmПакетыWindowsКомпонентыРабота с типами<здесь>
рабочие примеры имеются
------------ Дoбавленo в 20.26:
Под FPC теперь тоже работает
------------ Дoбавленo в 20.35:
Я еще хелп подрисовал вот он code_15868.sha

Assasin, А почему отказались и перешли от TObj в качестве парента для TType на наследование от ТObject. Только из-за совместимости со "старым" FPC?

А в чем будет преимущество? К тому же class более универсален и для FPC, как вы заметили выше, и для Delphi не надо вводить лишних {$ifdef F_P} для работы под FPC

Пойду-ка я "Книгу о КОЛ" перечту, может и к строгой иерархии наследования классов в Дельфи потянет, а там недалеко и до VCL.
это не надолго, в свете перехода на "новую" версию FPC
необходимость в большинстве подобных решений отпадет.

Minkovsky, если говорить о кол, то вообще-то идеология этой библиотеки прямо противоположна строгой иерархии классов VCL. Поэтому ваше замечание в высшей степени странное.
Если же говорить о наследовании в стандартном пакете HiAsm, то тут у простых(не GUI) классов завязки на KOL быть не должно - это обеспечивает некоторую степень переносимости кода ввиду не зависимости от конкретных библиотек. Поясните какие плюсы дает наследование от TObj, кроме потери свободы интеграции исходников в другие среды.

Прошу прощение за странное замечание

здесь не более чем антитеза, с просьбой ознакомится с принципами построения библиотеки, особенно в части отказа от классов, и наследования именно от TObj, и как следствие владение одним экземпляром vmt .
В своей реализации попрежнему придерживаюсь идеи наследования от TObj для всех кроме GUI, а последние от TControl (включающий только публичные методы и свойства).
Поля и приватные методы находятся в соподчиненном(CustomObj) TObj.

Добавил новые компоненты на svn:
Type_TypeMemory - копирует тип к себе в память, при очищении оригинала(источника) копия не очищается
Type_TypeCombine - комбинирует несколько типов в один, имя полученного типа будет взято с первого корректного типа, так же самостоятелен, как и Type_TypeMemory
Так же оптимизировал коды уже существующих компонентов и исправил несколько багов