My only concern about the variable is adding addition checks to performance. We have significant overhead going on during slot access already. One thought would be to make this a compilation option for high safety settings. I've recorded a Trac ticket for this issue.
Ian On Oct 2, 2009, at 3:21 PM, Alain Picard wrote: > "Leslie P. Polzer" > <s...@viridian-project.de> writes: > >> Would you propose that Elephant check the type as well >> when serializing slots? > > I'm a bit of two minds about it. I might be jaundiced in my > view because the systems I've used before was an O-R mapping > system, and there it made sense to assert in lisp---if you > didn't you eventually failed to store you data because of > a mismatch between the lisp type and the SQL column type. > > Hyperspec 7.5.3 states: >> * The contents of a slot will always be of type (and T1 ... Tn) where >> T1 ...Tn are the values of the :type slot options contained in all of >> the slot specifiers. If no slot specifier contains the :type slot >> option, the contents of the slot will always be of type t. The >> consequences of attempting to store in a slot a value that does not >> satisfy the type of the slot are undefined. > > So, the current "undefined" behaviour of Elephant is to "do the right > thing". Another valid undefined behaviour might be to assert. > > I think I hadn't analyzed this through before reporting the "bug". > Now that I realize it's a lisp semantics issue (rather than a > DB type safety issue) I'm inclined to think maybe the way to handle > it is as SBCL does (which I didn't know about - thanks for the tip!) > and let the user choose the correct behaviour. So we could have > a flag *ELEPHANT-ENFORCE-SLOT-TYPE-SAFETY-P* (defaulting to nil) > to catch such violations and turn them into asserts, on both > serialization and deserialization. > > This is, obviously, a very low priority matter, and truthfully, I'm > not sure I'd use it, at least not until my application was fully > debugged. Also, I think it would make migration issues when classes > are redefined even hairier than they currently are. > > So, no --- I'm not proposing it. :-) > > --Alain > > > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
