Set on ListModel

Hi all, I have a question.

I have a Class C. It has an instance variable s wich is a Set.
I want to create a Presenter for this class. Of course i use a ListPresenter
for s.
But , ListModel is not working with Set . ListModel new list: s.
When i add an element to the ListModel I have an error. If I do ListModel
new list: s asOrderedCollection I can add an element but this is not
reflected in s.
I understand all, but my question is: if I have a Set in a class in order to
do not admit repetitves elements , There is a method to use it with a List
Presenter?
In your experience , how can you do this kind of things.

TIA
Pablo

Pablo Digonzelli wrote:

>[...] if I have a Set in a class in order
> to do not admit repetitves elements , There is a method to use it with a
> List Presenter?

I don't think there is any way of doing this.  The problem is that a list
presenter knows that its elements have a position and an order, and the
elements of a Set don't have those.


> In your experience , how can you do this kind of things.

If you don't often add items to the Set, then you could just use an
OrderedCollection instead, and do an explicit #includes: test before adding to
it.  That wouldn't be /very/ much slower than using a Set if the collection is
reasonably small.

Otherwise, probably the only thing is to use two collections.  There are
several ways to approach it.

1) You could have a ListModel (on an OrderedCollection) as part of your Model.
The Model would expose that, and the Presenter would connect its ListPresenter
to it.  The Model would also contain a Set with the same contents as the
ListModel, and it would use that privately to check for duplicates when a new
element was added.

2) The model could contain just a Set, but would also have to generate its own
#itemAdded: notifications (and maybe #itemRemoved: too).  The Presenter would
keep a ListModel with a copy of the Set, and would use the notifications to
keep its copy up-to-date.

3) (more work, but cleaner) You could develop your own SetModel, which
understood the messages used by ListView/ListPresenter and also generated the
correct notifications, but which wrapped a Set instead of an OrderedCollection.
It would probably use an OrderedCollection (or ListModel) internally which held
a "copy" of the Set.

    -- chris

Chris
Thank for your answer

Regards
Pablo

"Chris Uppal" <[hidden email]> escribió en el
mensaje news:[hidden email]... adding to
> it.  That wouldn't be /very/ much slower than using a Set if the
collection is
> reasonably small.
>
> Otherwise, probably the only thing is to use two collections.  There are
> several ways to approach it.
>
> 1) You could have a ListModel (on an OrderedCollection) as part of your
Model.
> The Model would expose that, and the Presenter would connect its
ListPresenter
> to it.  The Model would also contain a Set with the same contents as the
> ListModel, and it would use that privately to check for duplicates when a
new
> element was added.
>
> 2) The model could contain just a Set, but would also have to generate its
own
> #itemAdded: notifications (and maybe #itemRemoved: too).  The Presenter
would
> keep a ListModel with a copy of the Set, and would use the notifications
to
> keep its copy up-to-date.
>
> 3) (more work, but cleaner) You could develop your own SetModel, which
> understood the messages used by ListView/ListPresenter and also generated
the
> correct notifications, but which wrapped a Set instead of an
OrderedCollection.
> It would probably use an OrderedCollection (or ListModel) internally which
held
> a "copy" of the Set.
>
>     -- chris
>
>
>