[jira] [Updated] (S2GRAPH-82) Merge DeferCache and FutureCache.

["DOYUNG YOON (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/S2GRAPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

DOYUNG YOON updated S2GRAPH-82:
-------------------------------
    Assignee: Daewon Jeong  (was: DOYUNG YOON)

> Merge DeferCache and FutureCache.
> ---------------------------------
>
>                 Key: S2GRAPH-82
>                 URL: https://issues.apache.org/jira/browse/S2GRAPH-82
>             Project: S2Graph
>          Issue Type: Improvement
>            Reporter: DOYUNG YOON
>            Assignee: Daewon Jeong
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently, under org.apache.s2graph.core.utils package, {{DeferCache}} and {{FutureCache}} has exactly same behavior except for their Types on Value to store.
> It would be better if we can merge these two class. The problem is that there is no common interface between asynchbase's {{Deferr}} and scala's {{Future}}.
> I was talk with [~daewon] and here is what we are suggesting, use type class.
> {noformat}
> trait CanDefer[A, M[_], C[_]] {
>   def promise: M[A]
>   def future(defer: M[A]): C[A]
>   def success(defer: M[A], value: A): Unit
>   def onSuccess[U](defer: C[A])(pf: PartialFunction[A, U])(implicit ec: ExecutionContext)
> }
> {noformat}
> and change DeferCache interface as follow.
> {noformat}
> * M[_] : container type that will be stored in local cache. ex) Promise, Defer.
> * C[_]: container type that will be returned to client of this class. Ex) Future, Defer.
> * A: actual element type that will be stored in M[_]  and C[_].
> class DeferCache[A, M[_], C[_]](config: Config)(implicit ec: ExecutionContext, canDefer: CanDefer[A, M, C])
> {noformat}
> First, define some type class CanDefer that has all common interfaces used in current DeferCache/FutureCache implementation. 
> Secondly, provide implicit value for both of Defer and Future.
> Third, change implimentation to use common type class. 
> This is what we have sofar, but any better idea would be appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)