For vs. For Each

[David]

Re: For vs. For Each

On 2004-08-12, Alvin Bruney [MVP] <> wrote:[color=blue]
> David Wrote[color=green]
>> Also, it eliminates a real ambiguity to the For Each statement, does
>> foreach iterate over the original collection, or over the entire
>> collection as it changes over time?[/color]
>
> I don't disagree with that. very good point indeed. but, the current
> approach makes it impossible to perform simple tasks inherent in UI
> programming (like removing multiselects in a listbox for instance).[/color]

Why is that difficult?

For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)
ListBox1.Items. Remove(item)
Next
[color=blue]
> Where
> such simple tasks are overly complicated, i believe the design should be
> reviewed.[/color]

Well, the case where you want to iterate over the original items while
mutating the collection is always trivial, just copy the references and
enumerate the copy. I don't see why we'd need a different enumerator
for that. And the case where you want to alter the iteration based on
actions during the iteration is

a) ambiguous and generally domain-specific, so not suitable for the CLR; and
b) probably a really bad idea.

There's a deeper issue too, which I won't really get into. But IMHO
there's a tendency for .Net developers to overuse dumb collections, and
put a lot of logic into various enumerations in controller classes that
should really be handled by the collection class itself. It's hard to
avoid doing that, but I think it's a bad habit and I'm not sure I want
to see more language features that encourage it.

[Alvin Bruney [MVP]]

Re: For vs. For Each

> For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)[color=blue]
> ListBox1.Items. Remove(item)
> Next[/color]

maybe if you spent 10 seconds testing your code BEFORE you posted it, you
would find out what all this discussion is about!
[color=blue]
> Well, the case where you want to iterate over the original items while
> mutating the collection is always trivial, just copy the references and
> enumerate the copy.[/color]

for a tutorial on how references work have a look at this most excellent
article:

http://www.dotnet247.com/247reference/a.aspx?u=http://www.pobox.com/~skeet

[color=blue]
> There's a deeper issue too, which I won't really get into. But IMHO
> there's a tendency for .Net developers to overuse dumb collections, and
> put a lot of logic into various enumerations in controller classes that
> should really be handled by the collection class itself. It's hard to
> avoid doing that, but I think it's a bad habit and I'm not sure I want
> to see more language features that encourage it.[/color]

I have no clue as to what you are trying to say. This apparently has no
bearing on the previous threads.
Or maybe you may want to try again AFTER reading the relevant threads.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"David" <dfoster@woofix .local.dom> wrote in message
news:slrncho6th .knv.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-08-12, Alvin Bruney [MVP] <> wrote:[color=green]
>> David Wrote[color=darkred]
>>> Also, it eliminates a real ambiguity to the For Each statement, does
>>> foreach iterate over the original collection, or over the entire
>>> collection as it changes over time?[/color]
>>
>> I don't disagree with that. very good point indeed. but, the current
>> approach makes it impossible to perform simple tasks inherent in UI
>> programming (like removing multiselects in a listbox for instance).[/color]
>
> Why is that difficult?
>
> For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)
> ListBox1.Items. Remove(item)
> Next
>[color=green]
>> Where
>> such simple tasks are overly complicated, i believe the design should be
>> reviewed.[/color]
>
> Well, the case where you want to iterate over the original items while
> mutating the collection is always trivial, just copy the references and
> enumerate the copy. I don't see why we'd need a different enumerator
> for that. And the case where you want to alter the iteration based on
> actions during the iteration is
>
> a) ambiguous and generally domain-specific, so not suitable for the CLR;
> and
> b) probably a really bad idea.
>
> There's a deeper issue too, which I won't really get into. But IMHO
> there's a tendency for .Net developers to overuse dumb collections, and
> put a lot of logic into various enumerations in controller classes that
> should really be handled by the collection class itself. It's hard to
> avoid doing that, but I think it's a bad habit and I'm not sure I want
> to see more language features that encourage it.
>[/color]

[Nick Malik]

Re: For vs. For Each

Hello David,

Your response certainly has a lot of emotion.

too bad it isn't coherent.

(that's my long winded way of say "what the heck are you talking about?")
[color=blue]
> Well, the case where you want to iterate over the original items while
> mutating the collection is always trivial, just copy the references and
> enumerate the copy.[/color]

And this is efficient how? If you want to do that, then do that... but
don't make my code pay for the overhead of that functionality because you
may want to do that once out of ten-thousand calls.

[color=blue]
> I don't see why we'd need a different enumerator for that.[/color]

You just described a different enumerator
[color=blue]
>
> There's a deeper issue too, which I won't really get into.[/color]

I was starting to hope, but then...
[color=blue]
> But IMHO[/color]

Oh darn, you went into it...
[color=blue]
> there's a tendency for .Net
> developers to overuse dumb collections, and
> put a lot of logic into various enumerations in controller classes that
> should really be handled by the collection class itself.
> It's hard to avoid doing that, but I think it's a bad habit and I'm not[/color]
sure I want[color=blue]
> to see more language features that encourage it.[/color]

So collections are a bad idea and we should all create "smart" classes that
wrap our types with logic, like how to do a sorted list, or how to do a
stack... (ignoring the debugged code for this that is in the CLR... that's
right, if you didn't write it, it isn't any good... Sorry... I forgot).

I promise not to get you started on generics.

[JohnLiu]

Re: For vs. For Each

"Cor Ligthert" <notfirstname@p lanet.nl> wrote in message news:<Ow7ZXuHgE HA.3536@TK2MSFT NGP12.phx.gbl>. ..[color=blue]
> From this document
>
> http://msdn.microsoft.com/library/de...tchPerfOpt.asp
>
> The performance difference between For and For Each loops does not appear to
> be significant.
>
> I hope this helps?
>
> Cor[/color]

It is not significant if you are working with Array-based collection
(almost all .NET collections are array based). Because an enumerator
in an array collection is pretty much just an index on a particular
position.

If you are working with Linked List-based collections, performance
with enumerators O(1) are vastly superior than index-based O(n), over
large collections this is easily visible.

jliu - www.ssw.com.au - johnliu.net

[David]

Re: For vs. For Each

On 2004-08-13, Nick Malik <nickmalik@hotm ail.nospam.com> wrote:[color=blue]
> Hello David,
>
> Your response certainly has a lot of emotion.[/color]

It really doesn't.
[color=blue]
> too bad it isn't coherent.
>
> (that's my long winded way of say "what the heck are you talking about?")
>[color=green]
>> Well, the case where you want to iterate over the original items while
>> mutating the collection is always trivial, just copy the references and
>> enumerate the copy.[/color]
>
> And this is efficient how? If you want to do that, then do that... but
> don't make my code pay for the overhead of that functionality because you
> may want to do that once out of ten-thousand calls.[/color]

It's not particularly efficient, but you only have two choices if you
want to mutate the collection: either copy the references or keep track
of the changes to the collection (with an event or something). Neither
is as efficient as keeping the collection read-only, and which is more
efficient depends entirely on what you're doing during the enumeration.

And if you want to enumerate over only the original items in the
collection, copying the references is your only reasonable choice. From
the point of view of efficiency, it doesn't matter whether you do this
explicitly or if .Net does it implicitly behind the scenes with a new
enumerator type.

For the example given, removing selected items from a ListBox, copying
the references is going to take a trivial amount of time compared to the
time it takes to redraw the ListBox.
[color=blue][color=green]
>> I don't see why we'd need a different enumerator for that.[/color]
>
> You just described a different enumerator[/color]

And I didn't need a new enumerator type or new language construct to
achieve the effect.
[color=blue][color=green]
>> There's a deeper issue too, which I won't really get into.[/color]
>
> I was starting to hope, but then...[/color]

Heh, somehow I doubt you were. This last part was putting a large
design issue into a very short paragraph, so it's understandable that
it's been misunderstood.
[color=blue][color=green]
>> But IMHO[/color]
>
> Oh darn, you went into it...
>[color=green]
>> there's a tendency for .Net
>> developers to overuse dumb collections, and
>> put a lot of logic into various enumerations in controller classes that
>> should really be handled by the collection class itself.
>> It's hard to avoid doing that, but I think it's a bad habit and I'm not[/color]
> sure I want[color=green]
>> to see more language features that encourage it.[/color]
>
> So collections are a bad idea and we should all create "smart" classes that
> wrap our types with logic, like how to do a sorted list, or how to do a
> stack... (ignoring the debugged code for this that is in the CLR... that's
> right, if you didn't write it, it isn't any good... Sorry... I forgot).[/color]

Well, now who's being emotional?

Obviously we should be using the collections, but IMO they should be
used as base classes or through composition much more often than they
are now. For example, I tend to use typed collections much more often
than the generic ArrayList, etc., and .Net gives me a rich set of tools
to create them with. In my experience, I'm not unusual at all in doing
this.

But once you begin to think of collections as being not just a dumb set
of objects, but a class representing of group of specific types, then
the next step is to start treating it like a full-fledged class in its
own right. And in classic OO terms, we shouldn't be iterating over the
privates of another class to get something done, we should be sending a
message to the class to ask it to perform the action.

Alvin's example is right on target. The only unique property a
ListBoxItemColl ection holds onto is whether an item is selected,
removing those items should be a public method of the collection class
(or possibly of the ListBox itself).

[David]

Re: For vs. For Each

On 2004-08-13, Alvin Bruney [MVP] <> wrote:[color=blue][color=green]
>> For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)
>> ListBox1.Items. Remove(item)
>> Next[/color]
>
> maybe if you spent 10 seconds testing your code BEFORE you posted it, you
> would find out what all this discussion is about![/color]

I did. The code works. Why do you think it doesn't? Out of curiosity,
have you run it?
[color=blue][color=green]
>> Well, the case where you want to iterate over the original items while
>> mutating the collection is always trivial, just copy the references and
>> enumerate the copy.[/color]
>
> for a tutorial on how references work have a look at this most excellent
> article:
> http://www.dotnet247.com/247referenc...box.com/~skeet[/color]

I may be missing something basic here (not a rare event), but for the
life of me I can't figure out what you think I'm missing. I've been to
Jon's pages quite often, BTW. I realize that for some reason we're in
the midst of fun usenet snarkiness here, but I'd appreciate it if you
could explain the error more clearly, because I really don't know what
you're getting at.

<snip>[color=blue]
>
> I have no clue as to what you are trying to say. This apparently has no
> bearing on the previous threads.[/color]

It's only tangentially related to the thread. Sorry, I thought I made
that clear.

[Nick Malik]

Re: For vs. For Each

> >[color=blue][color=green]
> > So collections are a bad idea and we should all create "smart" classes[/color][/color]
that[color=blue][color=green]
> > wrap our types with logic, like how to do a sorted list, or how to do a
> > stack... (ignoring the debugged code for this that is in the CLR...[/color][/color]
that's[color=blue][color=green]
> > right, if you didn't write it, it isn't any good... Sorry... I forgot).[/color]
>
> Well, now who's being emotional?
>[/color]

me. I was way too low on coffee. My apologies.

--- N

[Alvin Bruney [MVP]]

Re: For vs. For Each


Collection was modified; enumeration operation may not execute.
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.

Exception Details: System.InvalidO perationExcepti on: Collection was
modified; enumeration operation may not execute.

Source Error:


Line 50: private void Button2_Click(o bject sender, System.EventArg s e)
Line 51: {
Line 52: foreach(ListIte m li in ListBox1.Items)
Line 53: ListBox1.Items. Remove(li);
Line 54: }


running your code with a multiselect as opposed to one selection which i
suspect you didn't do.


Server Error in '/WebApplication2 ' Application.
--------------------------------------------------------------------------------

Collection was modified; enumeration operation may not execute.
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.

Exception Details: System.InvalidO perationExcepti on: Collection was
modified; enumeration operation may not execute.

Source Error:

Line 50: private void Button2_Click(o bject sender, System.EventArg s e)
Line 51: {
Line 52: foreach(ListIte m li in ListBox1.Items)
Line 53: if(li.Selected)
Line 54: ListBox1.Items. Remove(li);



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"David" <dfoster@woofix .local.dom> wrote in message
news:slrnchp5ph .qgv.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-08-13, Alvin Bruney [MVP] <> wrote:[color=green][color=darkred]
>>> For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)
>>> ListBox1.Items. Remove(item)
>>> Next[/color]
>>
>> maybe if you spent 10 seconds testing your code BEFORE you posted it, you
>> would find out what all this discussion is about![/color]
>
> I did. The code works. Why do you think it doesn't? Out of curiosity,
> have you run it?
>[color=green][color=darkred]
>>> Well, the case where you want to iterate over the original items while
>>> mutating the collection is always trivial, just copy the references and
>>> enumerate the copy.[/color]
>>
>> for a tutorial on how references work have a look at this most excellent
>> article:
>> http://www.dotnet247.com/247referenc...box.com/~skeet[/color]
>
> I may be missing something basic here (not a rare event), but for the
> life of me I can't figure out what you think I'm missing. I've been to
> Jon's pages quite often, BTW. I realize that for some reason we're in
> the midst of fun usenet snarkiness here, but I'd appreciate it if you
> could explain the error more clearly, because I really don't know what
> you're getting at.
>
> <snip>[color=green]
>>
>> I have no clue as to what you are trying to say. This apparently has no
>> bearing on the previous threads.[/color]
>
> It's only tangentially related to the thread. Sorry, I thought I made
> that clear.
>[/color]

[Jon Skeet [C# MVP]]

Re: For vs. For Each

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:[color=blue]
> Collection was modified; enumeration operation may not execute.
> Description: An unhandled exception occurred during the execution of the
> current web request. Please review the stack trace for more information
> about the error and where it originated in the code.
>
> Exception Details: System.InvalidO perationExcepti on: Collection was
> modified; enumeration operation may not execute.
>
> Source Error:
>
>
> Line 50: private void Button2_Click(o bject sender, System.EventArg s e)
> Line 51: {
> Line 52: foreach(ListIte m li in ListBox1.Items)
> Line 53: ListBox1.Items. Remove(li);
> Line 54: }
>
> running your code with a multiselect as opposed to one selection which i
> suspect you didn't do.[/color]

That's nothing like the code that David posted, however. Try:

foreach (ListItem li in new ArrayList(ListB ox1.Items))
{
ListBox1.Items. Remove(li);
}

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[David]

Re: For vs. For Each

On 2004-08-13, Alvin Bruney [MVP] <> wrote:[color=blue]
>
> Collection was modified; enumeration operation may not execute.
> Description: An unhandled exception occurred during the execution of the
> current web request. Please review the stack trace for more information
> about the error and where it originated in the code.
>
> Exception Details: System.InvalidO perationExcepti on: Collection was
> modified; enumeration operation may not execute.
>
> Source Error:
>
>
> Line 50: private void Button2_Click(o bject sender, System.EventArg s e)
> Line 51: {
> Line 52: foreach(ListIte m li in ListBox1.Items)
> Line 53: ListBox1.Items. Remove(li);
> Line 54: }[/color]

Now, with all that in mind, let's go back a couple of posts and look at
the code I actually posted....
[color=blue][color=green][color=darkred]
>>>For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)[/color][/color][/color]

You're iterating over the original collection, I am not. Now, I read
this in the VB.Net group so I just posted as VB, so I apologize if the
translation to C# threw you off, it's hard to know which group people
are posting from.

Try...

foreach(Object o in new ArrayList(ListB ox1.SelectedIte ms))
{
ListBox1.Items. Remove(o);
}
[color=blue]
> running your code with a multiselect as opposed to one selection which i
> suspect you didn't do.[/color]

No, you either had trouble converting the code or just didn't read it
closely enough, I'm not sure which. Anyway, now that you see the
correct code hopefully my comments will make a little more sense to you.

[David]

Re: For vs. For Each

On 2004-08-13, Nick Malik <nickmalik@hotm ail.nospam.com> wrote:[color=blue][color=green][color=darkred]
>> >[/color]
>> Well, now who's being emotional?[/color]
>
> me. I was way too low on coffee. My apologies.[/color]

Heh, caffeine deprivation strikes us all at some point...

[Alvin Bruney [MVP]]

Re: For vs. For Each

you are right.

i am guilty of skimming over the code and didn't catch the arraylist inside
the loop construct. this code is a gem by the way. it is the best approach i
have seen for this problem, and i have been keeping an eye out for a
feasible solution for a while (see a thread in csharp newsgroups about 8 -
10 months ago).

tomorrow, i'm gonna re-read the thread you posted a while back on that
topic. i believe you may be on to something.

thanks for your vigilance.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"David" <dfoster@woofix .local.dom> wrote in message
news:slrnchq9kl .rgn.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-08-13, Alvin Bruney [MVP] <> wrote:[color=green]
>>
>> Collection was modified; enumeration operation may not execute.
>> Description: An unhandled exception occurred during the execution of the
>> current web request. Please review the stack trace for more information
>> about the error and where it originated in the code.
>>
>> Exception Details: System.InvalidO perationExcepti on: Collection was
>> modified; enumeration operation may not execute.
>>
>> Source Error:
>>
>>
>> Line 50: private void Button2_Click(o bject sender, System.EventArg s e)
>> Line 51: {
>> Line 52: foreach(ListIte m li in ListBox1.Items)
>> Line 53: ListBox1.Items. Remove(li);
>> Line 54: }[/color]
>
> Now, with all that in mind, let's go back a couple of posts and look at
> the code I actually posted....
>[color=green][color=darkred]
>>>>For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)[/color][/color]
>
> You're iterating over the original collection, I am not. Now, I read
> this in the VB.Net group so I just posted as VB, so I apologize if the
> translation to C# threw you off, it's hard to know which group people
> are posting from.
>
> Try...
>
> foreach(Object o in new ArrayList(ListB ox1.SelectedIte ms))
> {
> ListBox1.Items. Remove(o);
> }
>[color=green]
>> running your code with a multiselect as opposed to one selection which i
>> suspect you didn't do.[/color]
>
> No, you either had trouble converting the code or just didn't read it
> closely enough, I'm not sure which. Anyway, now that you see the
> correct code hopefully my comments will make a little more sense to you.
>
>[/color]

[Alvin Bruney [MVP]]

Re: For vs. For Each

And the case where you want to alter the iteration based on[color=blue]
> actions during the iteration is
>
> a) ambiguous and generally domain-specific, so not suitable for the CLR;
> and
> b) probably a really bad idea.
>[/color]

There are issues with your approach. it really isn't domain specific or the
domain is large enough to be common to a lot of applications. From what i
understand from your solution, the problem is this approach may work well
for small collections but will not scale because you force a copy of the
collection per request.

Consider a large dataset where rows are to be removed. For n-items, you
introduce n copies. This effectively doubles your memory allocation. In a
high concurrency environment or in applications which run on finite memory
resources, this approach is not feasible because the cost of iteration is
prohibitive. Also, the cost is more expensive if the copy involves live
objects or objects in the collection which contain children as in the case
of hierarchical data. so it definitely is not trivial.

This is where a non-readonly collection would be more scalable and quicker.

I do agree that it is a good approach for small collections.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"David" <dfoster@woofix .local.dom> wrote in message
news:slrncho6th .knv.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-08-12, Alvin Bruney [MVP] <> wrote:[color=green]
>> David Wrote[color=darkred]
>>> Also, it eliminates a real ambiguity to the For Each statement, does
>>> foreach iterate over the original collection, or over the entire
>>> collection as it changes over time?[/color]
>>
>> I don't disagree with that. very good point indeed. but, the current
>> approach makes it impossible to perform simple tasks inherent in UI
>> programming (like removing multiselects in a listbox for instance).[/color]
>
> Why is that difficult?
>
> For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)
> ListBox1.Items. Remove(item)
> Next
>[color=green]
>> Where
>> such simple tasks are overly complicated, i believe the design should be
>> reviewed.[/color]
>
> Well, the case where you want to iterate over the original items while
> mutating the collection is always trivial, just copy the references and
> enumerate the copy. I don't see why we'd need a different enumerator
> for that. And the case where you want to alter the iteration based on
> actions during the iteration is
>
> a) ambiguous and generally domain-specific, so not suitable for the CLR;
> and
> b) probably a really bad idea.
>
> There's a deeper issue too, which I won't really get into. But IMHO
> there's a tendency for .Net developers to overuse dumb collections, and
> put a lot of logic into various enumerations in controller classes that
> should really be handled by the collection class itself. It's hard to
> avoid doing that, but I think it's a bad habit and I'm not sure I want
> to see more language features that encourage it.
>[/color]

[Alvin Bruney [MVP]]

Re: For vs. For Each

>There's a deeper issue too, which I won't really get into. But IMHO[color=blue]
>there's a tendency for .Net developers to overuse dumb collections[/color]

we need to hash this one out. provide all the details (get into it).

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"David" <dfoster@woofix .local.dom> wrote in message
news:slrncho6th .knv.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-08-12, Alvin Bruney [MVP] <> wrote:[color=green]
>> David Wrote[color=darkred]
>>> Also, it eliminates a real ambiguity to the For Each statement, does
>>> foreach iterate over the original collection, or over the entire
>>> collection as it changes over time?[/color]
>>
>> I don't disagree with that. very good point indeed. but, the current
>> approach makes it impossible to perform simple tasks inherent in UI
>> programming (like removing multiselects in a listbox for instance).[/color]
>
> Why is that difficult?
>
> For each item as Object In New ArrayList(ListB ox1.SelectedIte ms)
> ListBox1.Items. Remove(item)
> Next
>[color=green]
>> Where
>> such simple tasks are overly complicated, i believe the design should be
>> reviewed.[/color]
>
> Well, the case where you want to iterate over the original items while
> mutating the collection is always trivial, just copy the references and
> enumerate the copy. I don't see why we'd need a different enumerator
> for that. And the case where you want to alter the iteration based on
> actions during the iteration is
>
> a) ambiguous and generally domain-specific, so not suitable for the CLR;
> and
> b) probably a really bad idea.
>
> There's a deeper issue too, which I won't really get into. But IMHO
> there's a tendency for .Net developers to overuse dumb collections, and
> put a lot of logic into various enumerations in controller classes that
> should really be handled by the collection class itself. It's hard to
> avoid doing that, but I think it's a bad habit and I'm not sure I want
> to see more language features that encourage it.
>[/color]

[David]

Re: For vs. For Each

On 2004-08-14, Alvin Bruney [MVP] <> wrote:[color=blue]
> And the case where you want to alter the iteration based on[color=green]
>> actions during the iteration is
>>
>> a) ambiguous and generally domain-specific, so not suitable for the CLR;
>> and
>> b) probably a really bad idea.
>>[/color]
>
> There are issues with your approach. it really isn't domain specific or the
> domain is large enough to be common to a lot of applications.[/color]

The basic question upfront here is this: should changes to the
collection make during an enumeration affect the enumeration? If so,
how exactly should the enumeration be affected?

foreach(Diction aryEntry entry in MyDictionary)
{
MyDictionary.Ad d(CalculateNewK ey(), "New Entry");
MyDictionary.Re move(CalculateK eyToRemove());
}

Is that an infinite loop? Or does it depend on the values returned by
CalculateNewKey ()? Or does it run once for each entry that exists in
the dictionary at the start of the loop? Or does it run once for each
entry that exists at the start of the loop, unless that entry has been
removed from the list. There's a large number of possible definitions,
and each is significantly flawed in its own way.
[color=blue]
> From what i
> understand from your solution, the problem is this approach may work well
> for small collections but will not scale because you force a copy of the
> collection per request.[/color]

I do copy the collection, but I don't copy the objects contained in the
collection, only the references to those objects. There's a huge
difference between those two things.
[color=blue]
>
> Consider a large dataset where rows are to be removed. For n-items, you
> introduce n copies. This effectively doubles your memory allocation.[/color]

No. Because the rows aren't being copied, only references to the rows.
Memory allocation is significantly less than double.
[color=blue]
> In a
> high concurrency environment or in applications which run on finite memory
> resources, this approach is not feasible because the cost of iteration is
> prohibitive. Also, the cost is more expensive if the copy involves live
> objects or objects in the collection which contain children as in the case
> of hierarchical data. so it definitely is not trivial.[/color]

No, again because only references are being copied. There's a second
iteration, but it's impossible to know the performance effect of that
without knowing the internals of the collection (e.g., what is the cost
of a removal?).
[color=blue]
> This is where a non-readonly collection would be more scalable and quicker.[/color]

As I said to Nick, an enumerator over a non-readonly collection would
have to do the *exact same thing* at a minimum. The fact that some
enumerator type in the CLR does it instead of you doing it explicitly
doesn't affect scalability or performance at all.

In fact, though, performance in the CLR would be much worse than this,
how much worse depends entirely on how you chose to define the behavior
you're requesting. Copying the references as I did is trivial, but it
only works if I limit myself to very specific types of editing to the
underlying collection.