RE: [litwindow-users] Re: <map> as container

[yrs90 <yr...@ya...>]

> Is the sort order an inherent attribute of the 
> collection? Or is the sort order just a 'view' to the collection, 
> imposed by the user.... So, should sorting be part of the container 
> or not?

I had assumed that sort order should be part of the view rather than part of
the container.  Multiple views of data are not uncommon.  Multiple views
probably require that sort order be independent of the container.

> Iterators otoh will be short-lived objects used to access and iterate 
> the container. Their sort order can be changed without changing the 
> actual sort order of the underlying container.

This is an interesting perspective.  I had assumed that sorting would be
handled by the view itself rather than by an iterator.  Is there a way to
provide sorted iterators efficiently?

> Bookmarks otoh would be a much higher-level abstraction and should be 
> unique for every object inside the container.
>
> My current thinking is having bookmark as a unique 'address' of an 
> element in a container. Bookmarks should remain valid for all operations.
> ...
> A bookmark is just that, a bookmark. Most database engines support 
> bookmarks for rows inside a table. A bookmark remains valid as long as 
> the row exists, regardless of other insertion/deletion operations.

This sounds a lot like the iterator for a list or map.

> This high-level container might even contain more than one 'index'.

I don't see why it is desirable to have more than one index to a given
container element.  Well, that is unless you mean to have the index not only
indicate the item, but also the particular sorting that was used.  But that
seems unnecessary since element ordering is available from the view (or
through a sortable iterator).


> Idea 2:
> Insertion / deletion is never done by the container itself, but by some 
> control that owns the container.
>
> This would make the insertion/deletion easier, but you couldn't bind 
> more than one control to a container.

Restricting to a single association between a control and a container is too
constraining for a general framework, I think.  Although, so long as (a)
only one control could access a given container at any given time and (b) a
container could notify all bound controls when change had occurred, then I
think it would work for multiple controls bound to a single container too.

> Idea 1:
> Insertion / deletion is being handled by the container itself. 
> Interested objects are being notified.

The only troublesome part of this is that it takes a bit of work for a
control to gain access to its bound container.  I expect the access
mechanism could hidden, which would make this the more versatile approach.
For one thing, a deletion from a view might be achieved by setting a
container element attribute to "hidden".


Best regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]