JEP 11 suggestion: adding a |has| method

[Myk Melez]

I suggest adding a |has| method to JEP 11's simple persistent storage
that returns true or false depending on whether or not there is a key ->
value pair for that key:

jetpack.storage.simple.has(key)

Simple property bag interfaces often have |has| methods in addition to
their |get|, |set|, and |remove| methods, and they come in handy, even
though one can accomplish the same thing with |typeof get("foo") ==
"undefined"|, since the code is shorter to type and easier to grok.

In some cases |has| can also be more efficient than |get| when testing
sparse properties or those with large values.

-myk

[kixx]

+1 for has()

This also makes iteration more nicer.

[Aza]

+1.

Myk, can you add this to the JEP? We should also consider a |list| method, which returns all currently set values.

-- aza | ɐzɐ --

[Myk Melez]

On 06/18/2009 01:30 PM, Aza wrote:

+1.

Myk, can you add this to the JEP? We should also consider a |list| method, which returns all currently set values.

Yup, I have done so. Also, I agree that it makes sense to add list too.

-myk

[adw]

1) Instead of |list|, what do you think about |keys|, |values|, and |
pairs|? I guess everyone has an intuitive sense of what |list| means
-- probably "pairs" -- but it's not so clear.
2) Are the results of |list| and the other three methods I proposed
ordered? If not, should there be sorting methods too, or do we leave
that up to callers once they get their list?
3) Returning a list of values (instead of only one value as simple
storage does currently) raises an issue in relation to
asynchronicity. When and how do we notify callers of results? As
each batch of results is loaded, only after all results have loaded,
or both? If both, we'll give the caller each batch of results as they
come in, but do we also give the caller the complete result set after
all results have loaded, or is the all-results notification just a
flag to say all results have loaded?

In other words, which of the following methods do people like? (And
if you didn't like async |get| and |set|, you're going to love
this! :)

var allResults = [];

jetpack.storage.simple.pairs({
onOneResult: function (pair) {
console.log("Got pair: key=" + pair.key + ", value=" +
pair.value);
allResults.push(pair);
},
onResultBatch: function (batchOfPairs) {
batchOfPairs.forEach(function (pair) {
console.log("Got pair: key=" + pair.key + ", value=" +
pair.value);
allResults.push(pair);
});
},
onCompleteFlag: function () {
// Here I need allResults.
},
onCompleteWithResults: function (allPairs) {
// Here I don't need allResults, and if I don't need to be
notified of
// results as they load, I don't have to define onOneResult/
onResultBatch.
}
});

Something else that might be cool but for a later discussion is if I
could retrieve my entire simple storage as a JS object. Like,
jetpack.storage.simple.dictionary gets me { key1: val1, key2:
val2, ... }.

Drew

[Myk Melez]

On 06/23/2009 10:06 AM, adw wrote:

1) Instead of |list|, what do you think about |keys|, |values|, and |
pairs|?

I like it! We should probably make it compatible with the proposed native implementations of the keys and values properties in JavaScript (as described in ECMAScript 3.1?). Also, it might make sense to rename pairs to items per the Iterators and Generators proposal.

We could additionally implement an iterator for jetpack.storage.simple to make this even simpler for the common case of wanting to iterate keys and/or values:

for (let key in jetpack.storage.simple) { ... }
for each (let value in jetpack.storage.simple) { ... }
for (let [key, value] in jetpack.storage.simple) { ... }

Some of these forms might not be implementable yet with the current iterator support, though.

-myk

[Aza]

I'm taking inspiration from Python for all of these answers:

1) Instead of |list|, what do you think about |keys|, |values|, and |
pairs|?  I guess everyone has an intuitive sense of what |list| means
-- probably "pairs" -- but it's not so clear.

I agree with both you and Myk. |keys|, |values|, and |items| makes sense and is what Python does.
 

2) Are the results of |list| and the other three methods I proposed
ordered?  If not, should there be sorting methods too, or do we leave
that up to callers once they get their list?

In Python, they are unordered. Although, no matter what we do, some people will try to rely on the underlying behavior. Shall we order by, say, alphabetical ordering by key.
 

It might make sense to treat |items|, etc., as a forEach iterator. Meaning that it's as if you are looping over a an array like so:

myArray.forEach(function(x){
  console.log(x);
});

Thus, to iterate over items, keys, and values, you simply do:

jetpack.storage.simple.forItem(function(item){
  console.log( item );
});

If you want to build up a list of all items, then I suppose you can construct it manually. To be perfectly explicit, instead of calling them |item|, |key|, and |value|, we should call them |forItem|, |forKey|, and |forValue|. This seems like the cleanest solution?
 

Something else that might be cool but for a later discussion is if I
could retrieve my entire simple storage as a JS object.  Like,
jetpack.storage.simple.dictionary gets me { key1: val1, key2:
val2, ... }.

Ja, that would be cool.
 

[adw]

> In Python, they are unordered. Although, no matter what we do, some people
> will try to rely on the underlying behavior. Shall we order by, say,
> alphabetical ordering by key.

Now that I've thought about it more, I actually like unordered. It's
not clear that alphabetical ordering of keys is the common case, and
if you don't need it you're paying for something you're not going to
use. And then there's the question of how to order values without
keys.

> Thus, to iterate over items, keys, and values, you simply do:
>
> jetpack.storage.simple.forItem(function(item){
> console.log( item );
>
> });

I like this, but there's a wrinkle. Since it's asynchronous, you
can't assume that once you reach the end of the forEach that all
elements have been retrieved. So I propose to signal that iteration
is complete, the last element passed to the callback is null. This
would mean that simple storage can't store null values however, and it
currently can. Is that something we want to support? An alternative
would be passing undefined instead of null, since you can't store
undefined values, and then people who wanted to store null values
would have to explicitly check for value === undefined instead of !
value. That seems error-prone though.

Drew

[Eugene Lazutkin]

+1 on keys(), values(), and items(). If you have to choose, please
implement keys() first as more important and primary.