[elephant-devel] Bug, omission, or desired behaviour?

[Ian Eslick]

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"
> <sky at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel