[also sent to pc@p-cos.net]
CL-SERIALIZER calls CLOSER-MOP:SLOT-DEFINITION-ALLOCATION on a class object that might be a STANDARD-CLASS and might not (e.g. a STRUCTURE-CLASS). In SBCL, both of these are defined, but in Allegro 8.1, the only method on this generic function is on STANDARD-CLASS. Does it make sense to (1) extend the GF for the Allegro case in CLOSER-MOP to return NIL or some other sensible value (2) embed an appropriate check in the CL-SERIALIZER client code or (3) do you have another suggestion?
Thanks, Andrew Philpot USC ISI
Does it make sense to (1) extend the GF for the Allegro case in CLOSER-MOP to return NIL or some other sensible value (2) embed an appropriate check in the CL-SERIALIZER client code or (3) do you have another suggestion?
my take is basically (2): define separate (de)serializers for structure-object's and standard-object's instead of a shared (def serializer-deserializer slot-object ...) and use them appropriately from (def serializer-deserializer structure-object ... ) and (def serializer-deserializer standard-object +standard-object-code+ ...). maybe dealing with funcallable-standard-class, too if necessary.
this requires a good knowledge of the related part of the standard, and/or an environment with many enough lisps to be able to run practical tests quickly. i personally have neither at the moment, but Levy may have some words on this.
patches are very welcome, though! :)
my take is basically (2): define separate (de)serializers for structure-object's and standard-object's instead of a shared (def serializer-deserializer slot-object ...) and use them appropriately from (def serializer-deserializer structure-object ... ) and (def serializer-deserializer standard-object +standard-object-code+ ...). maybe dealing with funcallable-standard-class, too if necessary.
for the record, as far as i remember, i've implemented this meanwhile...
see the generics: - write-object-slots - read-object-slots
cl-serializer-devel@common-lisp.net
-
Andrew Philpot -
Attila Lendvai