core.cache

Split protocols from implementations

Details

  • Type: Enhancement Enhancement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

Hi Sean. I would like to propose a change mainly for starting being ClojureScript friendly.

It would be very useful to have all the protocols in one .cljc file and the implementations in different ones. This would open the doors for a ClojureScript port of some of the implementations down the road.

I don't know exactly how the split could be organized as I have just glanced the code but I am opening this issue to taste the waters about the idea.

Thank you!

Activity

Hide
Sean Corfield added a comment -

Since core.cache is designed to be extensible, the protocols are probably in use by existing user code out there so moving them would be a breaking change.

Show
Sean Corfield added a comment - Since core.cache is designed to be extensible, the protocols are probably in use by existing user code out there so moving them would be a breaking change.
Hide
Andrea Richiardi added a comment -

Oh that's too bad, could they be kept in the core file and move the implementations elsewhere?

Maybe we could go with clojure.core.cache2?

Show
Andrea Richiardi added a comment - Oh that's too bad, could they be kept in the core file and move the implementations elsewhere? Maybe we could go with clojure.core.cache2?
Hide
Sean Corfield added a comment -

Yeah, I think it would have to be a whole new set of namespaces at this point. Protocols in one common ns, and then probably each implementation in a separate ns so that some can be clj/cljs (like the BasicCache) and others can be either clj if they touch Java or cljc or cljs.

And core.memoize would probably need to follow suit since the two libs are coupled in various ways.

Show
Sean Corfield added a comment - Yeah, I think it would have to be a whole new set of namespaces at this point. Protocols in one common ns, and then probably each implementation in a separate ns so that some can be clj/cljs (like the BasicCache) and others can be either clj if they touch Java or cljc or cljs. And core.memoize would probably need to follow suit since the two libs are coupled in various ways.
Hide
Andrea Richiardi added a comment -

Sounds like a good plan, as reference I am going to leave also the link to cljs-cache here.

Show
Andrea Richiardi added a comment - Sounds like a good plan, as reference I am going to leave also the link to cljs-cache here.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: