[cl-store-devel] numeric code

[Hraban Luyat]

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.diff
Type: application/octet-stream
Size: 1539 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-store-devel/attachments/20111001/4c7eae26/attachment.obj>