Silly suggestion - thinking aloud

[Jon Skeet]

I've been briefly musing on what is probably a pretty silly idea, but
one which would no doubt benefit from being discussed and thoroughly
shot down in flames rather than being allowed to fester in my head.

Quite a lot of the time when I would logically use foreach in C#, I
can't because I want to do something extra: usually either delete the
current element from the backing collection or possibly change it. As
it is, I have to use a plain for loop or whatever. It works, but it's
not as pleasant as it might be.

So, here's some bizarre straw-man syntax for an alternative:

foreach (string x in myArrayList)
{
if (CheckForRemove(x))
enumerator(x).Remove();
else if (CheckForFoo(x))
enumerator(x).Set("foo");
else
Console.WriteLine ("Didn't change {0}", x);
}

There would be two extra interfaces as well as IEnumerator:
IRemovableEnumerator and IMutableEnumerator (or something like that).
The enumerator returned by an array would implement IMutableEnumerator,
whereas the enumerator returned by an ArrayList would implement
IMutableEnumerator and IRemovableEnumerator (if the ArrayList itself
were not read-only, of course). A collection could continue to be
enumerated if it had only been modified by the enumerator doing the
enumeration since the last step (rather than saying it couldn't have
been modified at all).

Any foreach loop which included the Remove action would cast the
enumerator to IRemovableEnumerator before launching into the main loop,
and likewise for Set/IMutableEnumerator.
As an example of a real-life use I'd have liked for this recently, I
needed to do:

for (int i=0; i < names.Count; i++)
{
names[i]=names[i].Trim();
}

where I might have been able to do:

foreach (string name in names)
{
enumerator(name).Set(name.Trim());
}

which I think is nicer.

Now for the problems:

o The syntax is horrible at the moment, partly because there may be
more than one enumerator going at a time so you need to identify
which enumerator you mean.

o There would need to be either an overloaded or new keyword to support
this - and a new keyword would make it a breaking change. Aargh!

o The check for an enumerator being mutable/removable is done at
runtime rather than compile time (and must be) - not nice.

o Some enumerations might be able to support IMutableEnumerator but
only in a weird way - if you're enumerating over a hashtable's keys,
what does it mean if you set it to something else? I guess this isn't
so bad, as you'd just not implement IMutableEnumerator in those
circumstances - but care would be needed.

There are bound to be more problems, and there may even be more
benefits or (more likely) much better ways of tackling the idea -
suggestions?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Daniel O'Connell]

few initial comments inline.
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

I've been briefly musing on what is probably a pretty silly idea, but
one which would no doubt benefit from being discussed and thoroughly
shot down in flames rather than being allowed to fester in my head.

Quite a lot of the time when I would logically use foreach in C#, I
can't because I want to do something extra: usually either delete the
current element from the backing collection or possibly change it. As
it is, I have to use a plain for loop or whatever. It works, but it's
not as pleasant as it might be.

I have to say, this is a feature i'd like too, lack of a capacity to modify
the enumerated object in a foreach is really annoying and often ends up
causing me to either use more for loops then i'd like, or seperating
operations in a manner i don't care for either.
So, here's some bizarre straw-man syntax for an alternative:

foreach (string x in myArrayList)
{
if (CheckForRemove(x))
enumerator(x).Remove();
else if (CheckForFoo(x))
enumerator(x).Set("foo");
else
Console.WriteLine ("Didn't change {0}", x);
}

Thing here is intellisense (i think the language should consider
intellisense as much as intellisense should consider the language, in these
days). There would be no simple way to determine if .Remove() & .Set() is
possible under this current syntax, as you noted the check would have to be
applied at runtime.
While documentation is a good thing, in-code documentation is always a help.
Perhaps something else is needed, maybe:
foreach removable (string x in myArrayList)
{
//do your stuff
}

That would allow you to force removable support(throwing an exception if its
not there, better to find that in the foreach statement, before you do
anything, i think), give intellisense a clue as to what your doing, etc. It
would also allow for extended safety, even if you have a removable
enumerator, without the removable keyword, you couldn't perform a remove
accidentally.

One explicit problem (or possibly a bonus) is that the removeable clause
could load a different enumerator causing unexpected results(perhaps ONLY
returning objects than can be removed safely, etc). That would be a matter
of design. And arguments could go either way.

anyway it is still not very pretty syntax either.
There would be two extra interfaces as well as IEnumerator:
IRemovableEnumerator and IMutableEnumerator (or something like that).
The enumerator returned by an array would implement IMutableEnumerator,
whereas the enumerator returned by an ArrayList would implement
IMutableEnumerator and IRemovableEnumerator (if the ArrayList itself
were not read-only, of course). A collection could continue to be
enumerated if it had only been modified by the enumerator doing the
enumeration since the last step (rather than saying it couldn't have
been modified at all).

Any foreach loop which included the Remove action would cast the
enumerator to IRemovableEnumerator before launching into the main loop,
and likewise for Set/IMutableEnumerator.
As an example of a real-life use I'd have liked for this recently, I
needed to do:

for (int i=0; i < names.Count; i++)
{
names[i]=names[i].Trim();
}

where I might have been able to do:

foreach (string name in names)
{
enumerator(name).Set(name.Trim());
}

which I think is nicer.

Now for the problems:

o The syntax is horrible at the moment, partly because there may be
more than one enumerator going at a time so you need to identify
which enumerator you mean.

This is kinda nasty, and hopefully someone else would have a suggestion as
to enhance the syntax, currently enumerator(x) works, but its not very
pretty. Naming enumerators could work but that would again begin to expand
code verbosity, possibly needlessly

foreach removable (string s in myArrayList) enumerator X
{
X.Remove(s);
//etc, etc
}

I don't find that pretty either, but maybe someone can morph it into a nice
syntax...
o There would need to be either an overloaded or new keyword to support
this - and a new keyword would make it a breaking change. Aargh!

Possibly more than one keyword, all in all.
I wonder how this would interact with iterators.
o The check for an enumerator being mutable/removable is done at
runtime rather than compile time (and must be) - not nice.

I addressed some bits of this above, which would allow for slightly better
runtime checking in a manner similar to how foreach works now.
o Some enumerations might be able to support IMutableEnumerator but
only in a weird way - if you're enumerating over a hashtable's keys,
what does it mean if you set it to something else? I guess this isn't
so bad, as you'd just not implement IMutableEnumerator in those
circumstances - but care would be needed.

There are bound to be more problems, and there may even be more
benefits or (more likely) much better ways of tackling the idea -
suggestions?

On top of that a type-filtered foreach would be nice, in mixed collections
it is very annoying to have to do

foreach (object o in objects)
{
if (o is string) {
//do string work
}
}

that too probably has alot of troubles, but i figured i would throw that old
idea into the fray here as well, ;)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Doug Forster]

If there was an enumerator function that gave access to the underlying
enumeration object wouldn't that be sufficient without further language
changes. Implementers could simply implement any interface they wished as
well as IEnumerator. This might make the code a bit more verbose but I think
better than embedding too many specifics in the language.

e.g.

foreach (string str in myCollection){
object o= enumerator(str);
if (o is IMyInterface)
((IMyInterface)o).DoSomething();
}

Regarding deletion, I always implement enumerators to work backwards which
helps sometimes but not always. Doesn't help with the builtin ones of
course.

Cheers

Doug Forster

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

I've been briefly musing on what is probably a pretty silly idea, but
one which would no doubt benefit from being discussed and thoroughly
shot down in flames rather than being allowed to fester in my head.

Quite a lot of the time when I would logically use foreach in C#, I
can't because I want to do something extra: usually either delete the
current element from the backing collection or possibly change it. As
it is, I have to use a plain for loop or whatever. It works, but it's
not as pleasant as it might be.

So, here's some bizarre straw-man syntax for an alternative:

foreach (string x in myArrayList)
{
if (CheckForRemove(x))
enumerator(x).Remove();
else if (CheckForFoo(x))
enumerator(x).Set("foo");
else
Console.WriteLine ("Didn't change {0}", x);
}

There would be two extra interfaces as well as IEnumerator:
IRemovableEnumerator and IMutableEnumerator (or something like that).
The enumerator returned by an array would implement IMutableEnumerator,
whereas the enumerator returned by an ArrayList would implement
IMutableEnumerator and IRemovableEnumerator (if the ArrayList itself
were not read-only, of course). A collection could continue to be
enumerated if it had only been modified by the enumerator doing the
enumeration since the last step (rather than saying it couldn't have
been modified at all).

Any foreach loop which included the Remove action would cast the
enumerator to IRemovableEnumerator before launching into the main loop,
and likewise for Set/IMutableEnumerator.
As an example of a real-life use I'd have liked for this recently, I
needed to do:

for (int i=0; i < names.Count; i++)
{
names[i]=names[i].Trim();
}

where I might have been able to do:

foreach (string name in names)
{
enumerator(name).Set(name.Trim());
}

which I think is nicer.

Now for the problems:

o The syntax is horrible at the moment, partly because there may be
more than one enumerator going at a time so you need to identify
which enumerator you mean.

o There would need to be either an overloaded or new keyword to support
this - and a new keyword would make it a breaking change. Aargh!

o The check for an enumerator being mutable/removable is done at
runtime rather than compile time (and must be) - not nice.

o Some enumerations might be able to support IMutableEnumerator but
only in a weird way - if you're enumerating over a hashtable's keys,
what does it mean if you set it to something else? I guess this isn't
so bad, as you'd just not implement IMutableEnumerator in those
circumstances - but care would be needed.

There are bound to be more problems, and there may even be more
benefits or (more likely) much better ways of tackling the idea -
suggestions?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Daniel O'Connell]

Main problem with this would be, for example you wanted deletion, you may
have a dozen different interfaces with a delete a member, one in different
third party application. So at the least a set of standard IRemovable type
interfaces would have to exist, even if not as a language change.

For removing, removing a further down object could be troublesome, but
replacing it with a place holder until the enumerator wraps up could fix
that (it would be easy to skip based on a NullObject placeholder or a skip
list).

Other problems include addition of elements. If your gonna have removable
foreach, you will need an addable one. In sorted lists adding an object can
be a real pain, because its location is not easily predicted. Should an
addition be loaded into the enumerator later on?

Adding such features to the language itself is not nessecerily a bad thing
if done properly. Forcing specifics into a language is often not a good
idea, but sometimes language level extentsions provide the better solution
for designers.

foreach access modifiers(in this case, can add, can remove, etc), sorts,
filters, etc at a language level could result in a much more standard method
of doing things, with explicit compile time type safety, instead of hoping
people follow uninforced interface guidelines and using runtime type checks.
Downside, of course, is it could cause other languages headaches in having
to support the new functionality, it would add complexity to both the
compiler and the understanding of the language, and writing enumerators
would get more difficult. Iterators may actually make writing such things
much simpiler, depending on the design.

"Doug Forster" <doug_ZAPTHIS_AT_TONIQ_ZAPTHIS_co.nz> wrote in message
news:uK**************@TK2MSFTNGP12.phx.gbl...

If there was an enumerator function that gave access to the underlying
enumeration object wouldn't that be sufficient without further language
changes. Implementers could simply implement any interface they wished as
well as IEnumerator. This might make the code a bit more verbose but I think better than embedding too many specifics in the language.

e.g.

foreach (string str in myCollection){
object o= enumerator(str);
if (o is IMyInterface)
((IMyInterface)o).DoSomething();
}

Regarding deletion, I always implement enumerators to work backwards which
helps sometimes but not always. Doesn't help with the builtin ones of
course.

Cheers

Doug Forster

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

I've been briefly musing on what is probably a pretty silly idea, but
one which would no doubt benefit from being discussed and thoroughly
shot down in flames rather than being allowed to fester in my head.

Quite a lot of the time when I would logically use foreach in C#, I
can't because I want to do something extra: usually either delete the
current element from the backing collection or possibly change it. As
it is, I have to use a plain for loop or whatever. It works, but it's
not as pleasant as it might be.

So, here's some bizarre straw-man syntax for an alternative:

foreach (string x in myArrayList)
{
if (CheckForRemove(x))
enumerator(x).Remove();
else if (CheckForFoo(x))
enumerator(x).Set("foo");
else
Console.WriteLine ("Didn't change {0}", x);
}

There would be two extra interfaces as well as IEnumerator:
IRemovableEnumerator and IMutableEnumerator (or something like that).
The enumerator returned by an array would implement IMutableEnumerator,
whereas the enumerator returned by an ArrayList would implement
IMutableEnumerator and IRemovableEnumerator (if the ArrayList itself
were not read-only, of course). A collection could continue to be
enumerated if it had only been modified by the enumerator doing the
enumeration since the last step (rather than saying it couldn't have
been modified at all).

Any foreach loop which included the Remove action would cast the
enumerator to IRemovableEnumerator before launching into the main loop,
and likewise for Set/IMutableEnumerator.
As an example of a real-life use I'd have liked for this recently, I
needed to do:

for (int i=0; i < names.Count; i++)
{
names[i]=names[i].Trim();
}

where I might have been able to do:

foreach (string name in names)
{
enumerator(name).Set(name.Trim());
}

which I think is nicer.

Now for the problems:

o The syntax is horrible at the moment, partly because there may be
more than one enumerator going at a time so you need to identify
which enumerator you mean.

o There would need to be either an overloaded or new keyword to support
this - and a new keyword would make it a breaking change. Aargh!

o The check for an enumerator being mutable/removable is done at
runtime rather than compile time (and must be) - not nice.

o Some enumerations might be able to support IMutableEnumerator but
only in a weird way - if you're enumerating over a hashtable's keys,
what does it mean if you set it to something else? I guess this isn't
so bad, as you'd just not implement IMutableEnumerator in those
circumstances - but care would be needed.

There are bound to be more problems, and there may even be more
benefits or (more likely) much better ways of tackling the idea -
suggestions?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

james <no****@hypercon.net> wrote:

I would say MS should just add the ability to remove from IEnumerator
and forget the special form of IRemovableEnumerator.
Would Remove then throw an exception if the collection didn't support
it (eg arrays, read-only collections, etc)?
But I can see
that it would probably lead to other problems I can't think of off hand.
Maybe they could just add a special Remove method like
MarkForRemovalWhileInForEach()
which would actually just mark it for removal until the loop exits

That sounds like it's asking for trouble to me - deferring things is
always going to have potentially nasty side-effects, unless the
programmer has a *really* good idea what's going on behind the scenes.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Daniel O'Connell]

inline
"AlexS" <sa***********@SPAMsympaticoPLEASE.ca> wrote in message
news:uK**************@TK2MSFTNGP09.phx.gbl...

Sorry if I miss the point,
however I can't get myself away from commenting.

Personally I think problem with deletion of items from collection/array
during foreach loop is compiler problem and partly problem of IEnumerator
implementations.

Whatever direction you enumerate, removal can be either programmed in
low-level MSIL, either in implementation completely transparently for
programmer and quite efficiently - and most important, without any issues
like "collection can't be modified". At least I don't see such issues. I
don't know why this was not implemented from the very start. Maybe framework designers know. I was very disappointed to see these exceptions when I
started with Beta2. I do not understand really, why we have to live with
them in 1.1 and it looks like further on.

I know that Eric mentioned that we don't want collections to change under
us, however when you call collection.Remove or RemoveAt method you
effectively change collection. So I miss the point of Eric's argument. And
correspondingly I do not see the need for additional interfaces or classes, which make collection enumeration more obscure and complex than it is
already.

Consider if your removal code was to add or remove an object 10 or 20 units
behind your current position. If the code wasn't carefully written, then the
index your accessing in your enumerator will skip or repeat a value and
probably cause trouble.
This is why ruling out modification of an object is a good idea, however,
allowing objects to be modified *THROUGH* the enumerator could work in some
situations.

However, another case comes about in Hashtables, SortedLists and the like,
where there is no guarenteed or a dynamic order, adding or removing a item
could throw off the enumeration in an unpredictable way, forcing the
IEnumerator writer to create a much more complex implementation, if they can
support it at all.

Because of this, the IEnumerator interface was written to be as simple as
possible and to cover only the very basic functionality. If Remove was to be
added, i can almost guarentee it will result in a new interface, in part
because modifying IEnumerator would break a great deal of code, but also
because Remove would not work in all cases safetly. It would have to be
selectivly applied, that makes IRemovableEnumerator a workable solution
where modifying IEnumerator would not be.
I would go in the direction of proper implementation of IEnumerators. Remove method must modify collection internal structure in such way, that
IEnumerator.Next or .Prev or whatever is used to run through elements in
foreach loop, will work properly. Intuitively we know that if we use foreach and remove first element, we expect next loop to be performed on second
element, which is next after first. If first element is the only one,
foreach should complete peacefully. Etc. It is logical for me. Current
exception seems illogical and indicates to me that implementation is
deficient.

Yes, there might be problems with sloppy coding. However we do not fight for development of support classes or interfaces, which will help to avoid
situations like

myobj=null;
myobj.mymethod();

which are causing null reference exception. Even if it is maybe possible to invent such object or INullCatcher, that myobj will catch such situations
after making it null, and maybe even do something useful.

Did I miss something important?

Rgds

[AlexS]

See inline

Consider if your removal code was to add or remove an object 10 or 20 units behind your current position. If the code wasn't carefully written, then the index your accessing in your enumerator will skip or repeat a value and
probably cause trouble.
That's why I mentioned the problem with calling method of disposed/nulled
object - this also might happen after several lines or in another thread
etc. I don't think that language constructs might help with this kind of
errors.
However, another case comes about in Hashtables, SortedLists and the like,
where there is no guarenteed or a dynamic order, adding or removing a item
could throw off the enumeration in an unpredictable way, forcing the
IEnumerator writer to create a much more complex implementation, if they can support it at all.
I am not sure that collection.Add is really useful in foreach. Do you have
some specific example to discuss?
However even for Add for every specific collection there are logical
scenarios.
Remove is logical always for me. I haven't seen (yet) sound example, which
demonstrates unpredictability here. That's why I pushed in the thread here
with my comments.

Because of this, the IEnumerator interface was written to be as simple as
possible and to cover only the very basic functionality. If Remove was to be added, i can almost guarentee it will result in a new interface, in part
because modifying IEnumerator would break a great deal of code, but also
because Remove would not work in all cases safetly. It would have to be
selectivly applied, that makes IRemovableEnumerator a workable solution
where modifying IEnumerator would not be.

It could be good point. However I do not have enough information to make
final conclusion. I really don't know how IEnumerator is implemented - I
mean algorithms for HashTable, SortedList etc.

Anyway, I did not mean to add Remove method to interface itself. I meant
more like that specific implementation of IEnumerator (MoveNext, Current)
should react properly on Remove inside foreach. In the context of specific
collection resulting behavior depends on how internally enumeration
(MoveNext) and addition/removal are realized, right? How internal pointers
are managed, which information is kept where, which checks are performed
during each iteration etc. Just by looking at available methods it is clear,
that allowing Remove in foreach will not break IEnumerator - MoveNext,
Current and Reset are staying, you don't need anything extra. You need just
to change implementation - and not necessarily of interface, but maybe of
Remove/Add methods only.

I remember, when I had to write my own linked lists - one- or
bi-directional - Add and Remove, which could be called anytime, were always
priority One and they modified behavior of MoveNext/MovePrev and Current.
Because of this experience I do not understand, why it is so crucial to
prevent Remove to happen from inside foreach.

Rgds

[Daniel O'Connell]

inline
"AlexS" <sa***********@SPAMsympaticoPLEASE.ca> wrote in message
news:O9****************@TK2MSFTNGP09.phx.gbl...

See inline

Consider if your removal code was to add or remove an object 10 or 20 units

behind your current position. If the code wasn't carefully written, then

the

index your accessing in your enumerator will skip or repeat a value and
probably cause trouble.

That's why I mentioned the problem with calling method of disposed/nulled
object - this also might happen after several lines or in another thread
etc. I don't think that language constructs might help with this kind of
errors.

languages constructs won't, quite agreeably, the language constructs Jon
proposed and the extensions i proposed are more for compiletype verification
and standarization, to avoid using Remove in situations where you shouldn't.
It should be noted that in most cases, using foreach, you don't access the
enumerator directly. I shoudl also note that my language construct
suggestion is the only one so far that would not result in a breaking
change, tho the syntax is horrid, ;).

However, another case comes about in Hashtables, SortedLists and the like, where there is no guarenteed or a dynamic order, adding or removing a item could throw off the enumeration in an unpredictable way, forcing the
IEnumerator writer to create a much more complex implementation, if they

can

support it at all.

I am not sure that collection.Add is really useful in foreach. Do you have
some specific example to discuss?
However even for Add for every specific collection there are logical
scenarios.
Remove is logical always for me. I haven't seen (yet) sound example, which
demonstrates unpredictability here. That's why I pushed in the thread here
with my comments.

A foreach with add is less likely to be useful, mutability and removability
are far more valuable concepts so far. Addition is very useful in
illustrating possible problems, and i brought it in solely as an
illustration of some of the problems i could see. I think that the design
should be made to handle the most basic possiblities(adding, removing,
getting, and setting), and then culled down to what really is useful to a
programmer during dicussion(at this stage of discussion anyway, although we
havn't got a good reason, that doesn't mean someone won't think of a reason
that addition within the foreach would be useful after reading this thread)

Because of this, the IEnumerator interface was written to be as simple as possible and to cover only the very basic functionality. If Remove was

to be

added, i can almost guarentee it will result in a new interface, in part
because modifying IEnumerator would break a great deal of code, but also
because Remove would not work in all cases safetly. It would have to be
selectivly applied, that makes IRemovableEnumerator a workable solution
where modifying IEnumerator would not be.
It could be good point. However I do not have enough information to make
final conclusion. I really don't know how IEnumerator is implemented - I
mean algorithms for HashTable, SortedList etc.

Anyway, I did not mean to add Remove method to interface itself. I meant
more like that specific implementation of IEnumerator (MoveNext, Current)
should react properly on Remove inside foreach. In the context of specific
collection resulting behavior depends on how internally enumeration
(MoveNext) and addition/removal are realized, right? How internal pointers
are managed, which information is kept where, which checks are performed
during each iteration etc. Just by looking at available methods it is

clear, that allowing Remove in foreach will not break IEnumerator - MoveNext,
Current and Reset are staying, you don't need anything extra. You need just to change implementation - and not necessarily of interface, but maybe of
Remove/Add methods only.
Where would you propose placing the Remove/Add/Set methods?
Inside the IEnumerator interface(that would be breaking)
as an inheritor of IEnumerator (IDyanmicEnumerator anyone?)
Remember, the code within the foreach must be capable of accessing the
Remove\Add\Set method easily, preferably with no complex casts or anything. I remember, when I had to write my own linked lists - one- or
bi-directional - Add and Remove, which could be called anytime, were always priority One and they modified behavior of MoveNext/MovePrev and Current.
Because of this experience I do not understand, why it is so crucial to
prevent Remove to happen from inside foreach.
Simple example:
Imagine if your linked list sorts objects based on size, on remove of an
object, the index in which the object is located causes everything ahead of
it for shift back, of course. But without knowing the size, it is more
difficult to determine where the shift will occur, the logic actually needs
to be inserted into the add\remove methods of the linked list itself. This
is just a case where some extended logic needs to be set, but it is
surmountable.
Also, should the object you jsut added to the head of the list, where you've
already been, be returned by foreach, or should it be dropped?

Complex Example:
You have a collection that stores objects in a tree, allowing for easy
location of a single object out of a large number. However it is a given
that all of your objects can be located in a linear manner (the objects are
always at the bottom level of a well balanced tree). Adding or removing a
node could cause a shift in the location of a great many nodes when the tree
is rebalanced, this would be a case where a change could be unpredictable.
This case too could be handled, tho it would involve alot of housekeeping
work to make sure there was no problems, probably an increase of 50-100
lines in your enumerator (and alot of practice to get it right), the node
shift code would have to do extra work to keep the enumerator up to date. It
could be very ugly in the end

Rgds

[ncaHammer]

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

There would be two extra interfaces as well as IEnumerator:
IRemovableEnumerator and IMutableEnumerator (or something like that).
The enumerator returned by an array would implement IMutableEnumerator,

Why all these ?
To avoid the "for(int i=0;.." syntax ?
Write a VS macro that expands this syntax
I find that in most cases you need the "i" and rarely the
IRemovableEnumerator or IMutableEnumerator
It can also move backwards<g>
which is the most common way to remove members from a list

I cannot understand this obsession (this is not directed to you only, but to
c# team also) to make foreach a super keyword (see iterators also),
since ever amateur developers do understand the "for(int i=0" syntax, i
wonder which is the target group of those "enhancements" ?

[ncaHammer]

"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:eH**************@TK2MSFTNGP11.phx.gbl...

Jon,

You might be interested in this column I wrote a while back:

http://msdn.microsoft.com/library/de...rp01212002.asp

you could just use
foreach (string s in new SortedList (hash).Keys)
or
foreach (string s in new ArrayList(hash.Keys))

[Jon Skeet]

ncaHammer <nc*******@nos.pamhot.mail.com> wrote:

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

There would be two extra interfaces as well as IEnumerator:
IRemovableEnumerator and IMutableEnumerator (or something like that).
The enumerator returned by an array would implement IMutableEnumerator,
Why all these ?
To avoid the "for(int i=0;.." syntax ?

Yes - because I believe it's clearer to say, "I want to go through all
the elements in a list, and by the way they're all strings, and replace
each element with a trimmed version" than code which does all that in
terms of indexes.
Write a VS macro that expands this syntax
The time taken to write code is vastly shorter than the time taken to
maintain it, usually - converting the more readable (IMO) format to the
less readable one doesn't really help much.
I find that in most cases you need the "i" and rarely the
IRemovableEnumerator or IMutableEnumerator
Certainly *sometimes* you would need the index even if you couldn't
change/remove the current element, but I don't find it happens this
often.
It can also move backwards<g>
which is the most common way to remove members from a list
But isn't that really only because it means you don't need to worry
about the "current position" changing?
I cannot understand this obsession (this is not directed to you only, but to
c# team also) to make foreach a super keyword (see iterators also),
since ever amateur developers do understand the "for(int i=0" syntax, i
wonder which is the target group of those "enhancements" ?

I can *understand* code that uses the index - but I would prefer code
that more directly expressed what I'm trying to do.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[james]

That instantly means that read-only collections and arrays (which are
fixed length, and thus can't have anything removed) can't be
enumerated. That's *much* too high a price to pay, IMO.

Well, that would be a problem wouldn't it ! I never use read only lists
so I have not run into that problem, yet.

A bigger issue for me is not being able to reference a null value
without getting an error. For example, SomeObject.SomeOtherObject.Name
if SomeOtherObejct is null you get an exception. It would be nice to just
get
null. For me, it means I have all those try catch blocks everywhere or I
must
have if ( if ( if ( if etc...

JIM

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

james <no****@hypercon.net> wrote:

A bigger issue for me is not being able to reference a null value
without getting an error. For example, SomeObject.SomeOtherObject.Name
if SomeOtherObejct is null you get an exception. It would be nice to just
get null. For me, it means I have all those try catch blocks everywhere or I
must have
if ( if ( if ( if etc...

Yikes no! I'd really rather not have that. If you're using a null
reference where you don't expect it to be null, you should be told
immediately in my view.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[james]

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

james <no****@hypercon.net> wrote:

A bigger issue for me is not being able to reference a null value
without getting an error. For example, SomeObject.SomeOtherObject.Name
if SomeOtherObejct is null you get an exception. It would be nice to just get null. For me, it means I have all those try catch blocks everywhere or I must have
if ( if ( if ( if etc...
Yikes no! I'd really rather not have that. If you're using a null
reference where you don't expect it to be null, you should be told
immediately in my view.

Oh, I dont have a problem with an exception, just not a fatal exception.
I would like to be able to avoid all those try/catch blocks. It gets to a
point
where every procedure should just have a built in try catch.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

james <no****@hypercon.net> wrote:

When it comes to databinding, and realtions where you want to
bind to a grid column you cannot check for null and you cannot insert
try catch blocks. Suppose you have a grid of Employees
and each Employee has the following relation path

Employee.ToDepartment.ToDepartmentManager.ToJobTit le.Name

Now you want to have a column in the grid that displays this department
manages job title. Unfortuantley, if the department manager is not assigned
then the middele of your path is broken, your program crashes !!

So you don't do that. You do it in separate stages - and what you do if
each "link" ends up being null may well be different anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[james]

Sorry, not acceptable to me. DataBinding should just work ! The grid
column
should just show a blank value since it is not assigned. This is a problem
MS does not seem to either understand or care about, but I can tell you
from experience that I have used other systems that handle this properly.
If I had to write code to handle this for all the thousands and thousands of
grid columns, text fields, comboboxes, list boxes etc... that I data bind to
I'd just shoot myself and get it over. Thankfully I have a solution that
solves this
for me. No, I can't say how :)
JIM
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

james <no****@hypercon.net> wrote:

When it comes to databinding, and realtions where you want to
bind to a grid column you cannot check for null and you cannot insert
try catch blocks. Suppose you have a grid of Employees
and each Employee has the following relation path

Employee.ToDepartment.ToDepartmentManager.ToJobTit le.Name

Now you want to have a column in the grid that displays this department
manages job title. Unfortuantley, if the department manager is not assigned then the middele of your path is broken, your program crashes !!

So you don't do that. You do it in separate stages - and what you do if
each "link" ends up being null may well be different anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too