Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

All work

Go to all work items
Select view

Select search mode

 
50 of

contains? broken for transient collections

Completed

Description

Behavior with Clojure 1.6.0:

Cause: This is caused by expectations in clojure.lang.RT regarding the type of collections for some methods, e.g. contains() and getFrom(). Checking for contains looks to see if the instance passed in is Associative (a subinterface of PersistentCollection), or IPersistentSet.

Approach: Expand the types that RT.getFrom(), RT.contains(), and RT.find() can handle to cover the additional transient interfaces.

Alternative: Other older patches (prob best exemplified by clj-700-8.diff) restructure the collections type hierarchy. That is a much bigger change than the one taken here but is perhaps a better long-term path. That patch refactors several of the Clojure interfaces so that logic abstract from the issue of immutability is pulled out to a general interface (e.g. ISet, IAssociative), but preserves the contract specified (e.g. Associatives only return Associatives when calling assoc()). With more general interfaces in place the contains() and getFrom() methods were then altered to conditionally use the general interfaces which are agnostic of persistence vs. transience.

Screening Notes re -10 patch

  • the extra conditions in RT add branches to some key functions. get already has a getFrom optimization, but there is no similar containsFrom or findFrom. Is it worth measuring the possible impact of these?

  • I believe the interface refactoring approach (not taken here) is worth separate consideration as an enhancement. If this is done, I think leveraging valAt would be simpler, e.g. allowing HashMap and ArrayMap to share code

  • it is not evident (to me anyway) why some API fns consume ILookup and others do not, among e.g. contains?, get, and find. Possible doc enhancement?

  • there is test code already in place (data_structures.clj) that could easily be expanded to cover transients. It would be nice to do this, or better yet get some test.check tests in place

Patch: clj-700-14.patch is based on clj-700-10, plus implements Rich's suggestion that entryAt and containsKey should live in ITransientAssociative2 and the existing concrete impls (ATransientMap, TransientVector) now implement it.

Environment

None

Attachments

13

Details

Assignee

Reporter

Labels

Approval

Ok

Patch

Code and Test

Priority

Affects versions

Fix versions

Created January 2, 2011 at 1:58 AM
Updated October 6, 2017 at 9:40 PM
Resolved October 6, 2017 at 9:40 PM

Activity

Show:

Alex MillerOctober 4, 2017 at 2:37 PM

Erik, re - no, that's a separate issue.

Alex MillerOctober 4, 2017 at 2:36 PM

Re -11 additions, by adding a method to ITransientAssociative, you have broken all external implementers (which includes several contrib library data structures and from glancing at github, many others). Maybe should make ITransientAssociative2 with the added method instead?

Erik AssumSeptember 28, 2017 at 7:48 PM

Does this solve as well?

Alex MillerSeptember 26, 2017 at 10:21 PM

Added -10 which sorts transient cases to the end of the checks.

Stuart HallowaySeptember 25, 2017 at 6:27 PM

If we are not going to get to the type hierarchy change any time soon, and if perf is acceptable (looks like it should be), I think we should consider applying the "RT knows about transients" approach in the current patch.

Flag notifications