ListModel - how seamless should it be?

I am wondering how seamless a ListModel should be.  Most code can treat it
as if it were an OrderedCollection without caring that it is a ListModel.
However a "copy do with deletions" type of operation needs to be coded
differently to handle the list model.  Should copy be implemented in
ListModel to also copy the list?

For example:
=================
"*** This is code I would use with an OrderedCollection."
oc := #('dog' 'cat' 'fish' 'bird') asOrderedCollection.
oc copy do: [ :each |
 (each includes: $f) ifTrue: [oc remove: each]].

"*** The same code but with a ListModel  will error saying nil does not
understand #includes: because the list in the ListModel is not copied."
oc := ListModel on: #('dog' 'cat' 'fish' 'bird') asOrderedCollection.
oc copy do: [ :each |
 (each includes: $f) ifTrue: [oc remove: each]].

"*** If we change the code to the following it will work as expected."
oc := ListModel on: #('dog' 'cat' 'fish' 'bird') asOrderedCollection.
oc list copy do: [ :each |
 (each includes: $f) ifTrue: [oc remove: each]].
=================

Should I expect ListModel to behave like OrderedCollection when I make a
copy, or am I expecting too much?

Chris

Chris

You wrote in message news:9f6k6k$2hopr$[hidden email]...
> I am wondering how seamless a ListModel should be.  Most code can treat it
> as if it were an OrderedCollection without caring that it is a ListModel.
> However a "copy do with deletions" type of operation needs to be coded
> differently to handle the list model.  Should copy be implemented in
> ListModel to also copy the list?
> ...
> Should I expect ListModel to behave like OrderedCollection when I make a
> copy, or am I expecting too much?

No, I don't think you are expecting too much. #copy on a ListModel should go
a bit deeper than the default shallow copy, and also copy the contained
collection. It needs a simple implementation of #postCopy along the same
lines as that of LookupTable. The less obvious question is what should
happen to the "events", but for consistency with Object I think the copy
should end up with no observers, certainly not the same collection of
observers.

Defect no. to be assigned, but it will be in the next patch.

Regards

Blair

> > Should I expect ListModel to behave like OrderedCollection when I make a
> > copy, or am I expecting too much?
>
> No, I don't think you are expecting too much. #copy on a ListModel should
go
> a bit deeper than the default shallow copy, and also copy the contained
> collection. It needs a simple implementation of #postCopy along the same
> lines as that of LookupTable. The less obvious question is what should
> happen to the "events", but for consistency with Object I think the copy
> should end up with no observers, certainly not the same collection of
> observers.
>

Isn't this also the case for TreeModel? For example:

t := TreeModel new.
t add: 1 asChildOf: nil.
t add: 2 asChildOf: 1.
t add: 3 asChildOf: 2.

TreePresenter showOn: t.

t copy remove: 3

removes the 3 from the original TreeModel (and from the copy). Also, if you
try this:

"Evaluate everything above the next comment:"
t1 := TreeModel new.
t1 add: 1 asChildOf: nil.
t1 add: 2 asChildOf: 1.
t1 add: 3 asChildOf: 2.
t2 := t1 copy.
TreePresenter showOn: t1.

"Now expand the TreeModel in the Presenter showing all the numbers."
"Then evaluate this:"
t2 remove: 3

in this case, the 3 is removed from both the TreeModels as in the first
example and you get a walkback (Not Found: 3) as soon as the mouse cursor is
moved above the TreePresenter, which still shows the 3.


Regards
Mikael
[hidden email]

"Mikael Svane" <[hidden email]> wrote in message
news:9fbmu6$3bg8t$[hidden email]...
> > > Should I expect ListModel to behave like OrderedCollection when I make
a
> > > copy, or am I expecting too much?
> >
> > No, I don't think you are expecting too much. #copy on a ListModel
should
Not necessarily. The implementation of #copy for TreeModel is far less clear
cut, since trees are recursive structures. Should #copy be defined as a
#deepCopy for trees, or at least one deep enough to copy all the nodes, if
not the values? Perhaps it should, but I don't know whether it would be much
use in practice since it will not be fast.
We are willing to accept reasoned arguments either way.

Regards

Blair

> > Isn't this also the case for TreeModel?
>
> Not necessarily. The implementation of #copy for TreeModel is far less
clear
> cut, since trees are recursive structures. Should #copy be defined as a
> #deepCopy for trees, or at least one deep enough to copy all the nodes, if
> not the values? Perhaps it should, but I don't know whether it would be
much
> use in practice since it will not be fast.
> We are willing to accept reasoned arguments either way.

I am not sure that this is "reasoned arguments", but I will try:

I wouldn't expect #copy to be the same as #deepCopy for TreeModels, since
#deepCopy isn't very useful for TreeModels. Try this:

a := Object new.
b := Object new.
c := Object new.
t := TreeModel new.
t add: a asChildOf: nil.
t add: b asChildOf: a.
t add: c asChildOf: b.
TreePresenter showOn: t.

t deepCopy remove: c

This gives a "Not found: an Object" error since of course the object in c
isn't in the new TreeModel.

The way I would expect #copy to work would be to copy the nodes but not the
values. It would be slow, but more logical than the current behaviour since
this way TreeModels would behave the same way as Collections when copied.
The model (collection or tree) is new, but the contents is the same.

Best regards,

Mikael
[hidden email]