I can't agree.
Firstly, the overhead of a counter would be negligible.
Secondly, the counter is a counter for the iteration - not the group
members. If it emulates exactly the code example already posted here,
then the ordering (or not) of the items within their group is not
relevant.
Given that, I think the feature would be useful.
There is, of course, the problem that the counter would be misused as
an indicator of group sequence rather than a simple iteration count,
but that doesn't seem to be a significant consideration in other
design decisions
At a very high level, I agree that having a counter in a for each loop
would be an interesting feature. it would give coders more options. But
I am not usre the cost is worth the price.
1. Opportunity costs:
=====================
If you were to choose between POCO (plain old CLR objects) for Entity
Framework and having a counter in a for each loop, which would you
choose?
You might acutually want the counter, but what about better support for
variants/invariants or better drag and drop that does not box you in, or
perhaps easy extensibility through the MEF, or perhaps a billion other
things that might be included in a release.
Where does counter in a for each fit in this group of features?
Especially when you consider a change from:
int counter = 0;
for each (Blah b in o.blahs)
{
int currentItem = counter;
counter++;
}
to
for (int i=0;i<o.blahs.Count;i++)
{
//Actually not necessary, for comparison only
int currentItem = i;
}
solves the problem without adding this feature to the framework.
As for it not creating a performance issue, I was not talking end user
code. I meant the necessary changes to the framework to support:
for each (Blah b in o.blahs)
{
int currentItem = foreach.counter;
}
there is also a cost associated with examining the impact to the
framework, as this is a deep underlying change if all for each iterated
objects have to be supported. And, if they don't support ALL, then
people wil be writing "Microsoft sucks" because the Foo object will not
iterate and give an accurate counter. Ouch!
Is lost opportunities in more impactful areas (my opinion) worth adding
this feature? I say no.
2. Perf costs in the .NET Framework:
====================================
Underneath the hood, there is a lot that has to be done. Major impact to
perf? Probably not, but there are some classes that inherently do not
support the idea of order. In fact, with some classes, where the actual
items end up in memory can alter the order, which means you code changes
every time. Not a bad thing as long as you are submitting back via
primary key, but imagine making changes and then applying them to a
reconstituted collection believing your counter will enforce changes to
the correct object? Yuck! So, Microsoft coders end up adding a lot of
overhead to those objects so you can persist back in a disconnected way?
Double yuck!
Once again, the feature has to support all objects that support
IEnumrable, even those optimzed for IEnumarable to the point they can be
consituted differently based on memory position.
---------
As for the user adding the counter to his for each loop? I could care
less how he solves the problem, but refactoring the code to a for() loop
over a for each loop is a bit less kludgy. I was simply pointing out the
kludge.
in this particular instance, there is little danger. But using this type
of methodology develops a habit and that habit could lead to instances
where the code does not work logically, although it compiles and runs
fine. Logic errors, ultimately, are the hardest to debug.
Peace and Grace,
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Twitter: @gbworld
Blog:
http://gregorybeamer.spaces.live.com
*******************************************
| Think outside the box! |
*******************************************
