Hi folks,
I'm working on a custom serialization on top of cl-serializer.
Some questions have come up:
1) Why aren't SERIALIZE and DESERIALIZE generic functions? I could just specialize them this way or augment them with auxiliary methods.
2) How am I supposed to make cl-serializer actually use my custom definer? Do I really need to define my own mapper? This would be quite unwieldy as I would have to always specify this mapper then which makes the whole point of the definer a bit moot since I had to write a wrapper for this anyway...
3) Is this the intended way to support custom types in cl-serializer?
4) What id space is intended for custom types? The one between +first-reserved-code+ and +last-reserved-code+?
I also noticed that the definer 'serializer-deserializer' isn't exported.
Thanks as always,
Leslie
- Why aren't SERIALIZE and DESERIALIZE generic functions? I could just specialize them this way or augment them with auxiliary methods.
because that's much slower than an optimized typecase.
cl-serializer is more about being flexible, fast and producing small output... than about being a serializer to safely interchange data beween various versions, etc. it doesn't mean that it's not good for that, but the balance is towards flexibility from foolproofness, for example.
as of your question: you can fall back to a generic dispatch. take a look at the :serializer-mapper keyword arg of serialize. it is a function that should return three values, documented at default-serializer-mapper (in a patch i've just pushed), which is the default that you can call from your customized one.
same applies to the deserialize part.
- How am I supposed to make cl-serializer actually use my custom definer? Do I really need to define my own mapper? This would be quite unwieldy as I would have to always specify this mapper then which makes the whole point of the definer a bit moot since I had to write a wrapper for this anyway...
you are right. probably there should be a method-dispatching-serializer-mapper out of the box, that first checks for standard-object's and calls a defgeneric to do their serialization for a bit easier extensibility.
- Is this the intended way to support custom types in cl-serializer?
dunno, you should describe a real-world example where the standard standard-object serializer is not good for your needs, how it is not good, and what you want to achieve.
we never needed such a customization, therefore the above mentioned method-dispatching-serializer-mapper doesn't exist. and we even serialize continuations into the database...
- What id space is intended for custom types? The one between +first-reserved-code+ and +last-reserved-code+?
that is reserved for cl-serializer itself. again, i'm not sure you really need to extend that space, but if you do, then you only need one code, the rest is up to you how is encoded.
I also noticed that the definer 'serializer-deserializer' isn't exported.
don't think too much into what is exported, or at least into what is not exported. probably we simply never needed it outside cl-serializer, so we didn't even consider exporting it.
hth,
- Why aren't SERIALIZE and DESERIALIZE generic functions? I could just specialize them this way or augment them with auxiliary methods.
because that's much slower than an optimized typecase.
There was a similar discussion about the Elephant serializer some time ago. Someone mentioned that SBCL has dispatch speed at least on par with typecase. He might have been wrong, of course. I haven't benched it.
- Is this the intended way to support custom types in cl-serializer?
dunno, you should describe a real-world example where the standard standard-object serializer is not good for your needs, how it is not good, and what you want to achieve.
I need to change some slots of the object afterwards to make them valid in the new environment (unbind one, process another).
we never needed such a customization, therefore the above mentioned method-dispatching-serializer-mapper doesn't exist. and we even serialize continuations into the database...
Ah, on a tangent: is this functionality of your app SBCL-specific?
Leslie
we never needed such a customization, therefore the above mentioned method-dispatching-serializer-mapper doesn't exist. and we even serialize continuations into the database...
Ah, on a tangent: is this functionality of your app SBCL-specific?
it's done using cl-delico (the facto
cl-serializer-devel@common-lisp.net