SuperObject совместимый с FPC для Win/Linux

[Makhaon]

Всем добрый день, возможно кому-то пригодится:
https://github.com/Makhaon/superobject
пишите вопросы, если будут.

[serbod]

Как-то все сложно.. Я проще сделал, и лицензия простейшая (MIT). И там же сериализатор Bencode:
https://github.com/serbod/dbitems/blob/ ... torage.pas

отдельно сериализатор JSON - https://github.com/serbod/dbitems/blob/ ... torage.pas

Где-то еще валяются сериализаторы XML и ini, но после Bencode на них даже смотреть не хочется.

[wavebvg]

А почему сериализация производится в ассоциативный массив? Почему не в объект, который, как мне видится, куда как проще использовать и поддерживать на практике?

[serbod]

А почему сериализация производится в ассоциативный массив? Почему не в объект, который, как мне видится, куда как проще использовать и поддерживать на практике?

А в чем же разница между объектом и ассоциативным массивом, с точки зрения сериализации? =)

[wavebvg]

А в чем же разница между объектом и ассоциативным массивом, с точки зрения сериализации? =)

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

И да, нескромный вопрос: зачем создавать TStringStream, чтобы прочитать/записать в строку поток байт?

[serbod]

ради сериализации использовать отдельную реализацию ассоциативного массива, несовместимую с базовыми реализациями (TStrings и т.п.) кажется чересчур расточительным занятием.

Для того, чтобы элементы данных самоуничтожались когда их никто не использует, необходимо обращаться с ними не как с классами, а как с интерфейсами. Только у переменных типа Interface есть подсчет ссылок, у переменных типа Pointer или Class подсчета ссылок нет.
К сожалению, для хранения типов Interface обычные контейнеры вроде TStrings или TList не подходят. Поэтому, для создания ассоциативного массива с поддержкой reference counting приходится извращаться. Если вы знаете способ лучше - поделитесь.

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

И да, нескромный вопрос: зачем создавать TStringStream, чтобы прочитать/записать в строку поток байт?

Так исторически сложилось. =) Сейчас переделаю.