Collections set accessors

[michael.grounds]

Using the .NET framework and some other third party API's I've noticed
that objects with a collection property generally don't have a set
accessor? That is to say I have not yet managed to find one yet.

After searching around I've not managed to find a reason why other
than that it forces you to use the the provided .Add(), .Remove(),
RemoveAt() methods of the collection.

Why cant I do something like:

this.imageList1.Images = myImageCollection;

Any elements in myImageCollection would have had to have used these
methods anyway so I can't see why I would have to enumerate and add
individually.

I cannot seem to find any information as to why this is? Is there an
unspoken rule or design pattern that discourages setting all the
collection elements in one go? Is this the same across other
languages/platforms?

Thanks

 

[Peter Duniho]

[...]
Any elements in myImageCollection would have had to have used these
methods anyway so I can't see why I would have to enumerate and add
individually.

I cannot seem to find any information as to why this is? Is there an
unspoken rule or design pattern that discourages setting all the
collection elements in one go? Is this the same across other
languages/platforms?

As is the case for many of the collection types, ImageListCollection has
an AddRange() method that can be used to add a group of items all at once.

One reason I can think of to prevent replacement of the collection
itself is that there may be events on the collection to which some other
class has subscribed (for example, raised when changes are made to the
collection). If the collection could simply be replaced, then either
those events simply get silently unsubscribed (effectively), or a lot of
extra work has to be done to copy all of the subscriptions to a newly
set collection.

To further complicate the above, what if the collection is subclassed,
and it's the derived class that contains the events, but the class using
the collection isn't even aware of those events?

There are probably other problems that come up if the collection
instance itself is allowed to be replaced. Since you can in fact copy
the entire contents of one collection to another, I think that the
restriction is not as big a problem as one might think.

Pete

 

[Mikeyranks]

[...]
Any elements in myImageCollection would have had to have used these
methods anyway so I can't see why I would have to enumerate and add
individually.

I cannot seem to find any information as to why this is? Is there an
unspoken rule or design pattern that discourages setting all the
collection elements in one go? Is this the same across other
languages/platforms?

As is the case for many of the collection types, ImageListCollection has
an AddRange() method that can be used to add a group of items all at once.

One reason I can think of to prevent replacement of the collection
itself is that there may be events on the collection to which some other
class has subscribed (for example, raised when changes are made to the
collection). If the collection could simply be replaced, then either
those events simply get silently unsubscribed (effectively), or a lot of
extra work has to be done to copy all of the subscriptions to a newly
set collection.

To further complicate the above, what if the collection is subclassed,
and it's the derived class that contains the events, but the class using
the collection isn't even aware of those events?

There are probably other problems that come up if the collection
instance itself is allowed to be replaced. Since you can in fact copy
the entire contents of one collection to another, I think that the
restriction is not as big a problem as one might think.

Pete

Thanks, That does make sense though perhaps the imageList was a bad
example - I just opened a fresh instance of studio and it was the
first thing I could get my paws on before writing this post.

I'm actually using an IBindinglist implementation and have created
some custom usercontrols that bind to these - for the momnet I cannot
see anything else subscribing to them. I guess I could bind the
control to its collection property in the OnLoad event and anything
else added would be seen in the control. Though creating a set
accessor that binds after the property changes uses far less code as I
needn't foreach when the IBindingList comes out of the middle tier.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Using the .NET framework and some other third party API's I've noticed
that objects with a collection property generally don't have a set
accessor? That is to say I have not yet managed to find one yet.

The reason is that 99.9999% of the times you want to add/remove an item in
the collection, you do not create/delete the collection itself.