[cl-store-devel] numeric code

[Hraban Luyat]

It turns out that my patch breaks when referred objects come into the
picture because (store-object) is called recursively from within
(output-type-code). This patch adds one line to the latter function,
decreasing *stored-counter* before entering recursion. Hopefully this
makes the behaviour added by this patch transparent.

Comments and suggestions welcome.

Greetings,

Hraban

2011/10/1 Hraban Luyat <hraban at 0brg.net>:
> Or use both: whenever output-type-code receives a byte, use the
> classic efficient model. Whenever it receives something else, encode
> that code itself with store-object and return it verbatim on restore.
> It is up to the user to make sure that such objects are compatible
> with generic method dispatch through eql (e.g. symbols and larger
> numbers).
>
> This alleviates the 0-255 constraint (larger numbers now also
> possible), keeps the old behaviour for backwards compatibility and
> efficiency reasons and alleviates the need to do manual bookkeeping of
> codes.
>
> Only tested briefly against clisp, but the patch is pretty simple.
>
> Comments welcome, let me know what you think.
>
> Greetings,
>
> Hraban
>
> 2011/10/1 Nikolaus Demmel <demmeln at in.tum.de>:
>>
>> Am 30.09.2011 um 23:32 schrieb Hraban Luyat:
>>> Is there a reason for the necessity of codes being numeric? I thought
>>> it would be nice to use symbols. Specifically, the class name of an
>>> object. That way each class has an obvious unique code and I do not
>>> need to manually keep track of which ones are in use and which ones
>>> are not. Then I can forget about register-code entirely.
>>
>> Without knowing too much detail about the implementation, I guess it is mainly an implementation reason. The code is directly used for serializing. IIRC you can only use 256 different values anyway, at least with the default backend.
>>
>> I like your idea though. I guess one would have to maintain a table of codes and corresponding symbols and use codes still for actual serialization, otherwise there could be a very significant (space) overhead if you dump big data.
>>
>>> I would like to comment further on cl-store in this otherwise quite
>>> abrupt e-mail, but I have not really used it yet. So far the API looks
>>> cool, though. Thanks for maintaining and writing cl-store.
>>
>>
>> As Sean is looking for a new owner for cl-store I guess you will probably have to implement this yourself.
>>
>> Best,
>> Nikolaus
>