tabWidget: should option `ordered` be used for two (seemingly) different things?

[megoth]

I'm writing tests for the tabWidget, and came upon a couple of strange behaviors. First of all, whether or not options.ordered is true or false:

  function sync () {
    if (options.ordered) {
      orderedSync()
    } else {
      // @@ SORT THE values
      orderedSync()
    }
  }

Second, it's used to decide whether items should be objects from a list of triples, or if they should be in a collection:

    if (options.ordered !== false) {
      // default to true
      return store.the(subject, options.predicate).elements
    } else {
      return store.each(subject, options.predicate)
    }

I think it's fine to use an option for this, but is ordered the best name for it? Maybe collection would be better? (And the to remove the if-branches for function sync, or have option ordered actually do something different there.)

For now, I'll wait with writing tests for option until I understand this better.

[timbl]

Agreed the name may be confusing. It means 'I am passing you an ordered thing' rather than 'you should be an ordered thing'.

The justification is that in RDF if you want to pass something ordered it has to be a collection. Logically for an unordered list, you would pass an RDF Set but we don't have sets yet).
If you pass a subject/predicate pair, then you are effectively passing an unordered set. So in that case, the tabWidget asserts its own order for consistency, by just sorting the nodes.

What I guess we decided NOT to support was a really unordered thing, maintaining a UI with a initially random arbitrary (but constant through changes) order. Don't see the value in that - an imposed sort() order is fine.

I'd be happy to change the option name to 'collection' or orderedCollection or valuesAreCollection or 'collection' or keeping it as 'ordered'. What do you think?

[megoth]

What I guess we decided NOT to support was a really unordered thing, maintaining a UI with a initially random arbitrary (but constant through changes) order. Don't see the value in that - an imposed sort() order is fine.

So we only need to sort unordered stuff, i.e. the elements does not originate from a collection, correct? Which means that

  function sync () {
    if (options.ordered) {
      orderedSync()
    } else {
      // @@ SORT THE values
      orderedSync()
    }
  }

Can probably be changed to

  function sync () {
    if (options.ordered === false) { // possible rename to options.collection
      sortUnordered() // renaming orderedSync to sortUnordered
    }
  }

I'm thinking this since elements from a collection will always be ordered anyway, right?

I'd be happy to change the option name to 'collection' or orderedCollection or valuesAreCollection or 'collection' or keeping it as 'ordered'. What do you think?

I think collection is a bit easier to understand for most developers. The only challenge is existing tools out there that uses this; should we deprecate ordered, or just replace it with collection? Or should we keep ordered but rely on it being documented so that others understand?