[Chandler-dev] Re: annotating selection

John Anderson john at osafoundation.org
Sat Apr 1 16:45:09 PST 2006

Alec Flett wrote:
> John Anderson wrote:
>> We originally considered doing this and it can be done. However, two 
>> different users may want to have a sort named "date" that works 
>> differently, e.g. one date sorts using one locale and another sorts 
>> by another locale. So as long we build in a mechanism to resolve how 
>> different names map to the same or different sorts it's fine. We 
>> choose the current mechanism because it was easier than implementing 
>> such a mechanism.
> this is a degenerate case. If we need that case we can build something 
> in where the index name is "date_en_US" or something, but I think 
> building an entire extra layer of indirection to support this seems 
> like premature generalization to me.
> In general, I view an index as a sort of static sort of items.. When 
> you have a bunch of unrelated indexes like "date", "displayName" an so 
> forth, then we shouldn't be tweaking what individual indexes do, but 
> rather choose the right index from the pool of those available to us.
I would prefer an index mechanism that didn't depend on a name, but 
instead depended only on the kind of index you wanted. I'd like to say 
"give me the index that sorts using a particular comparison function" 
and if such an index already exists, it would return it, otherwise it 
would create it, then return it.

>> Storing the selection on the block leads to the following problem: 
>> Consider the case where you want a single block that is used to view 
>> many different contents (I think the calendar currently works this 
>> way). If you store the selection on the block then your selection 
>> becomes incorrect when you switch to a new contents. Storing the 
>> selection with the contents allows you to restore the collection. 
>> Personally, I think the selection is more closely tied to the index 
>> of the collection that makes up the contents, rather than the Block.
> Maybe I wasn't clear in my proposal. I did not suggest storing the 
> actual selection on the block, but rather the name of the index on the 
> collection that is used for selection in that particular block.
> For instance, the dashboard block might store its current selection in 
> the "dashboard" index in self.contents. I did fail to mention that 
> this index would be a numeric, unsorted index independent of other 
> shared indexes like "date" and "displayName". A block's self.contents 
> could change, to become a different collection, with a different 
> "dashboard" index with a different selection... so swapping in 
> different collections would work just fine. If some specialized block 
> comes along called "spiralview" then it could store its selection in 
> the collection in the "spiralview" index.
I'm not sure I completely understand the proposal, but if it allow us to 
store separately, the block, the selection and the index, and later hook 
them up in differently, e.g. replace the index and selection for a 
block, I think it should work. Usually, but not always the selection and 
index go together.
>>> The tricky case is 1). How do we keep selection off the main 
>>> collection and yet have it update automatically when items are 
>>> added/removed from the collection? I thought first about 
>>> Annotations. We still haven't solved the problem of how to maintain 
>>> selection when changing the current index, so perhaps instead we 
>>> could think about the selection as a sort of Annotated 
>>> dictionary-style attribute, keyed off of some part of the block. 
>>> Basically you'd be hanging a bunch of selections off of the collection,
>> It's not difficult to maintain the selection when switching the index 
>> -- it's a task on my list that I haven't finished doing.
> Right, so I'm proposing a mechanism: have one consistent index that is 
> used for selection in a given block. Make that index independent of 
> the currently selected items.
> Its true we'd loose the efficiency that might be gained by making the 
> table's selection ranges match the table's sort index, but we've never 
> actually shown that we need that efficiency. Just trying to avoid over 
> engineering this in the name of premature optimization :)
So it the trade-off between the way things work and what you're 
proposing the following?: Changing the selection for many items would be 
less efficient, but if two different Blocks happened to use the same 
exact sort we could reuse the index? i.e. waste less space at the 
expense of slower performance?

I also suspect that giving up on handling large lists efficiently might 
end up being a mistake.
> Alec

More information about the chandler-dev mailing list