delite/Store Array / Observable Array support

[cjolif]

Quite some time ago @asudoh suggested that delite/Store should in addition to dstore input support Array / Obserable Array support. If that work is done at delite/Store level this should allow to leverage it automatically in all consumers like list, select, treemap.

I'm not sure if @asudoh will have time again working on this, but I think the idea was very nice and we should definitely keep that in mind.

[wkeese]

PR in #410.

[wkeese]

I never saw a detailed spec for this. In particular, about filtering and sorting.

The PR in #410 implements filtering leveraging dstore's Filter code, at the cost of making the application code require dstore/Filter. The PR has limited support for sorting, specifically that sorting does not work in conjunction with dynamic updates/additions to the array.

The filtering part seems strange to me. (If we are OK with having a dependency on dstore, then why not leverage dstore/Memory, and just map ObservableArray changes to updates on the dstore/Memory object?)

Perhaps it's better to support either a simple hash (ex: {id: 123}) and/or a user-defined function (that takes an item and returns true/false). OTOH, it's nice to have a consistent filter API regardless of whether the source is a dstore or an ObservableArray. @cjolif, @asudoh, @harbalk, thoughts?

[asudoh]

If I understand the discussion correctly, I'd like any features that are not in plain array left to Store, so that our widget can be used without any knowledge (or very least knowledge) of Store and the new store adopter. BTW, as I stated earlier, I'd like a spec, too, covering the concept as well as each API.

[harbalk]

Hi @wkeese, the reason I made the query based on the dstore/Filter is that deliteful/Combobox widget is using it with querying. Also my previous implementation couldn't deal with some tests of deliteful.
With @cjolif we thought about moving the dstore/Filter (copy) in delite or decor since it is already used by deliteful/Combobox.js.

[wkeese]

I didn't realize that deliteful/Combobox was using dstore/Filter to form its query. That's an interesting point.

You said you talked about copying the dstore/Filter code into decor. That means that you were trying to break the hard dependency on dstore? From reading the dstore/Filter spec it sounds like Combobox could just do something like:

{type: "match", args: [this.list.labelAttr, rexExp]}

rather than requiring dstore/Filter and doing:

(new Filter()).match(this.list.labelAttr, rexExp)

That's probably better than copying the whole Filter.js file over.

@asudoh, I'd still like to see the spec too, although the adapter code is finally simple enough to understand pretty easily now. IIRC just a constructor and three main functions. I don't understand what your:

I'd like any features that are not in plain array left to Store

comment meant though. Can you elaborate?

[asudoh]

@wkeese I don’t have much knowledge about the problem space of Store, but just concerned that adding many features to the adapter would make the adapter complex, which is hard for widget authors and possibly for widget users to work with.

I’m not getting the concept of the store adapter without a spec. For example, the code seems to be called “array to store adapter”. Then it effectively would create an store with an array, which reminds me of “memory store” concept, like this? @wkeese brought up dstore/Collection interface in our private conversation, which may be good for the code to adhere to.

[harbalk]

HI @asudoh, just for precision the adapter is an adapter for the array to delite/Store not dstore/Store.
As you can see there is also an adapter for dstore to the delite/Store.

[asudoh]

This @harbalk for clarification. Then here's what I'd like to see:

1. Define a unified "collection" API. Rather than sticking to current delite/Store API I'd like to see something that's intuitive for native array users (or for dstore/Collection users).
2. Create API wrappers, one is from array to 1., another is from dstore to 1.

One idea for 1. is based on array's splice-based observation API (rather than current itemXXXed() APIs), possibly with query/filtering support. If it's impossible then it's time for us to look at dstore/Collection. (Note that dstore/Colleciton is a pure interface, so basing our API on dstore/Collection won't introduce any chained module dependencies)