Clojure

clojure.spec/keys requires input collections conform to clojure.core/map?

Details

  • Type: Defect Defect
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: Release 1.9
  • Fix Version/s: Release 1.10
  • Component/s: None
  • Labels:
  • Approval:
    Vetted

Description

I would like to use specs to validate Datomic entities. However, `s/keys` is too restrictive in that it requires input collections to conform to `clojure.core/map?` instead of some more primitive interface (for example clojure.lang.ILookup or clojure.lang.Associative).

Activity

Hide
Alex Miller added a comment -

s/keys uses IPersistentMap's Iterable support for iterating through all entries for validation. ILookup and Associative do not support iteration. So, that's why it is the way it is. But, understand the desire.

Show
Alex Miller added a comment - s/keys uses IPersistentMap's Iterable support for iterating through all entries for validation. ILookup and Associative do not support iteration. So, that's why it is the way it is. But, understand the desire.
Hide
Alex Miller added a comment -

Datomic entities are seqable so maybe that's a potential path (would be slower for actual PHMs though).

Show
Alex Miller added a comment - Datomic entities are seqable so maybe that's a potential path (would be slower for actual PHMs though).
Hide
Odin Standal added a comment -

Thanks for following up. So any ideas or guidance on how to use clojure.spec with Datomic entities?

Show
Odin Standal added a comment - Thanks for following up. So any ideas or guidance on how to use clojure.spec with Datomic entities?
Hide
Alex Miller added a comment -

For now, you could use into to pour an entity into a PHM before validating. I hesitate to suggest it, but that could even be in the spec with a leading conformer.

Show
Alex Miller added a comment - For now, you could use into to pour an entity into a PHM before validating. I hesitate to suggest it, but that could even be in the spec with a leading conformer.
Hide
Alex Miller added a comment -

Moving this into 1.9 for the moment just so we don't lose it. Not sure whether we can or will actually do anything with this though.

Show
Alex Miller added a comment - Moving this into 1.9 for the moment just so we don't lose it. Not sure whether we can or will actually do anything with this though.
Hide
Alex Miller added a comment -

This is related to CLJ-2080 as it's the same basic issue of what map-of and every-kv actually expect as valid inputs, which is: something that seqs to map entries. We can't really write a predicate for it without an interface "ISeqsToMapEntries" (intentionally bad name) to indicate this. java.util.Map, IPersistentMap, etc imply this, but an object can seq to map entries without meeting all the constraints of those much broader interfaces. ILookup does not and should not imply this.

Show
Alex Miller added a comment - This is related to CLJ-2080 as it's the same basic issue of what map-of and every-kv actually expect as valid inputs, which is: something that seqs to map entries. We can't really write a predicate for it without an interface "ISeqsToMapEntries" (intentionally bad name) to indicate this. java.util.Map, IPersistentMap, etc imply this, but an object can seq to map entries without meeting all the constraints of those much broader interfaces. ILookup does not and should not imply this.

People

Vote (9)
Watch (7)

Dates

  • Created:
    Updated: