[cl-serializer-devel] Architecture

[Attila Lendvai]

>  1) 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.


>  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...


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.


>  3) 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...


>  4) 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,

-- 
 attila