On Mon, Mar 14, 2016 at 08:42:40PM -0700, Aaron Wolf wrote: > On 03/14/2016 08:08 PM, Peter Harpending wrote: > > On 03/14/2016 05:10 PM, Bryan Richter wrote: > >> 1. I'm not sure the Eq instances of MechPatron and MechProject are > >> sound. As defined, `==` is the moral equivalent of checking that the > >> two values cannot both exist in the database at the same time > >> (database uniqueness), but that's not quite the same thing as being > >> the same value. > > > > So, I think I redid this between when you wrote this review and > > now. Now, the `Eq` instance makes sure the external keys are equivalent. > > > > instance Eq MechPatron where > > m1 == m2 = mechPatronExternalKey m1 == mechPatronExternalKey m2 > > > > instance Ord MechPatron where > > compare = comparing mechPatronExternalKey > > > > instance Eq MechProject where > > m1 == m2 = mechProjectExternalKey m1 == mechProjectExternalKey m2 > > > > instance Ord MechProject where > > compare = comparing mechProjectExternalKey
Yes, that's what I saw. I think it's necessary and good that there is a uniqueness constraint on external keys within the database. That uniqueness constraint does not extend to Haskell land, however, where it is completely possible to create two different MechPatron values with the same external key field. What's more, I am not sure we would want to prevent that. We should only "optimize" Eq to compare just the one field (and by 'compare' I mean both `(==)` and `comparing`) when it is impossible for that field be non-unique within a program. Further, we should only ensure THAT invariant when there is a clear and present need for it. Otherwise, Eq will occasionally produce surprising results.
signature.asc
Description: Digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/dev
