1000835 - Make remove() eat an array of IDs for the DataStore interface

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Gene Lian (I already quit Mozilla)]

get() can do this. Why not remove()? This can also make sure data records can be deleted transactionally.

Hope to align this to the W3C version at: http://airpingu.github.io/data-store-api/index.html

Comment 1

[Andrea Marchesini [:baku]]

  Promise remove(DataStoreKey... id, optional DOMString revisionId = "");

This is not a valid syntax for WebIDL. If we want to have an array, it must be:

  Promise remove(sequence<DataStoreKey> id, optional DOMString revisionId = "");

but this doesn't follow what the get does.

Comment 2

[Gene Lian (I already quit Mozilla)]

So this is a webidl compiler issue?

Comment 3

[Andrea Marchesini [:baku]]

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #2)
> So this is a webidl compiler issue?

No, the problem is: if you call:

remove(1, 2, 'hello world');

how can the binding know if there are 3 ids (1, 2, 'hello world') or 2 ids (1, 2) and 1 revisionId ('hello world') ?

Comment 4

[Gene Lian (I already quit Mozilla)]

Oh! I see. Thanks for the clarification!

And I'm worrying about if we're forced to use |sequence<DataStoreKey> id| then the content has to call: |remove([1])| instead of |remove(1)| even if there is only one record to be removed. As you mentioned, it won't behave symmetrically like |get(1)|.

I start thinking "type..." is a bad design in general. It stops us adding optional parameters after it. Using "any" sounds more explicit. Platform can check its type (array or single element) to have different path. Just checked all of webidl. All the codes using "type..." is for the last argument.

Comment 5

[(no longer active)]

(In reply to comment #4)
> Oh! I see. Thanks for the clarification!
> 
> And I'm worrying about if we're forced to use |sequence<DataStoreKey> id| then
> the content has to call: |remove([1])| instead of |remove(1)| even if there is
> only one record to be removed. As you mentioned, it won't behave symmetrically
> like |get(1)|.

Yes, I don't think that would be an improvement.

> I start thinking "type..." is a bad design in general. It stops us adding
> optional parameters after it. Using "any" sounds more explicit. Platform can
> check its type (array or single element) to have different path. Just checked
> all of webidl. All the codes using "type..." is for the last argument.

This kind of feedback should go to public-script-coord.  :-)