[cl-store-devel] numeric code

[Hraban Luyat]

.. and here is the new patch.

2011/10/1 Hraban Luyat <hraban at 0brg.net>:
> 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
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-package-2.diff
Type: application/octet-stream
Size: 1567 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-store-devel/attachments/20111001/1e65451d/attachment.obj>