get the iterator

[Marco]

I need to get a iterator from any generic collection.
public class .... GetIterator(Object collection)
{

.....

}

How can I do this with reflection?

Thanks in advance.

[Tim Haughton]

"Marco" <te******@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I need to get a iterator from any generic collection.
public class .... GetIterator(Object collection)
{

....

}

How can I do this with reflection?

I'm not sure I'm following you. Collections (meaning any class implementing
ICollection) implicitly implement IEnumerable. This means that you can call
GetEnumerator on them to get an enumerator (iterator). There's no need for
reflection.

If I've misunderstood feel free to post back.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Oliver Sturm]

Marco wrote:

I need to get a iterator from any generic collection.
public class .... GetIterator(Object collection)
{

....

}

How can I do this with reflection?

Why would you do this with reflection? If you know that the given type is
a collection and it has an iterator, you can just cast it to an
IEnumerable and get the iterator from there:

IEnumerable enumerable = collection as IEnumerable;
if (enumerable != null) {
// get the iterator from enumerable.GetEnumerator()
// or just use it directly with foreach
}

Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Tim Haughton]

"Oliver Sturm" <ol****@sturmnet.org> wrote in message
news:xn****************@msnews.microsoft.com...

Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

Hi Oliver, I see your name's down for the nosh with Hugh MacLeod and chums
at December's London Geek dinner. I hope to make it myself - it will be nice
to put a face to the Usenet posts.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Marco]

Thanks very much.I would like control tha collection implement
IEnumerable with reflection.

Can I put your code in a function and and return a IEnumerable or null?
How?

[Oliver Sturm]

Hi Tim,

Tim Haughton wrote:

Hi Oliver, I see your name's down for the nosh with Hugh MacLeod and chums
at December's London Geek dinner. I hope to make it myself - it will be
nice
to put a face to the Usenet posts.

Yes, that would be great. I haven't met most of the guys (and girls!) yet
myself, so I'm looking forward to that. Hope you can make it!
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Oliver Sturm]

Marco wrote:

Thanks very much.I would like control tha collection implement
IEnumerable with reflection.
I'm sorry, I don't understand exactly what you want to do with Reflection.
Can I put your code in a function and and return a IEnumerable or null?
How?

The magic of the "as" operator makes that extremely easy:

IEnumerable GetIEnumerable(object potentialCollection) {
return potentialCollection as IEnumerable;
}
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Marco]

it's right.
Thanks very much.
I would like control that collection implement IEnumerable with
reflection but it's a wrong way.

[Helge Jensen]

Oliver Sturm wrote:

IEnumerable enumerable = collection as IEnumerable;
if (enumerable != null) {
// get the iterator from enumerable.GetEnumerator()
// or just use it directly with foreach
}

Why use "collection as IEnumerable"? If it's supposed to be a collection
just use a cast. What would be a reasonable behaviour if collection is
not IEnumerable?

I'd write:

IEnumerator it = ((IEnumerable)collection).GetEnumerator();

or for iteration:

foreach ( Foo foo in ((IEnumerable)collection )
...

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Tim Haughton]

"Helge Jensen" <he**********@slog.dk> wrote in message
news:43**************@slog.dk...

Why use "collection as IEnumerable"? If it's supposed to be a collection
just use a cast. What would be a reasonable behaviour if collection is
not IEnumerable?

Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Reasonable behaviour is entirely dependent on its context. It's just a code
snippet so reasonable behaviour doesn't really come into it.

But there are technical differences between C style casting and using the
'as' operator. If we define a method...

private void Bob()
{
object obj1 = new Class1();
Class1 class1 = (Class1) obj1;
Class1 class2 = obj1 as Class1;
}

The IL is different for each cast:

..method private hidebysig instance void Bob() cil managed
{
// Code size 21 (0x15)
.maxstack 1
.locals init ([0] object a,
[1] class ClassLibrary2.Class1 c,
[2] class ClassLibrary2.Class1 d)
IL_0000: newobj instance void ClassLibrary2.Class1::.ctor()
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: castclass ClassLibrary2.Class1
IL_000c: stloc.1
IL_000d: ldloc.0
IL_000e: isinst ClassLibrary2.Class1
IL_0013: stloc.2
IL_0014: ret
} // end of method Class2::Bob

C Style casting uses the castclass opcode which, as you know, throws an
exception if the type atop the stack is not of the desired type. The as
operator uses the isinst opcode instead, returning a null reference in the
event of the type atop the stack not being of the desired types.

There are other considerations of course - the as operator can't use
conversion operators, whereas the C style cast can. The C style cast is
slower than the as operator in success scenarios, and *much* slower than the
as operator in failure scenarios.

I guess the best place for the C style cast is when failure would indicate
an exceptional circumstance.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Oliver Sturm]

Helge Jensen wrote:

Why use "collection as IEnumerable"? If it's supposed to be a collection
just use a cast. What would be a reasonable behaviour if collection is not
IEnumerable?

I'd write:

IEnumerator it = ((IEnumerable)collection).GetEnumerator();

or for iteration:

foreach ( Foo foo in ((IEnumerable)collection )
...

Well, the way the sample code is given (and requested by the OP) there
wasn't really any guarantee that the object would be a collection. In that
case the cast might be unsafe, that's why I'm using "as". The whole method
the OP was posting about would be kind of pointless if it had a parameter
of a collection type to start with, wouldn't it? :-)

And it's better to use

IEnumerable enumerable = collection as IEnumerable;
if (enumerable != null)
...

than

if (collection is IEnumerable) {
IEnumerable enumerable = (IEnumerable) collection;
...
}

because with the "as" operator, you get to check for the correct type and
acquire the interface at the same time. I usually use casts only if either
I'm completely sure that the target type is available or if, for some
reason, I want to assert that the target type *must* be available at the
point.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Steve Walker]

In message <43**************@slog.dk>, Helge Jensen
<he**********@slog.dk> writes

Oliver Sturm wrote:

IEnumerable enumerable = collection as IEnumerable;
if (enumerable != null) {
// get the iterator from enumerable.GetEnumerator()
// or just use it directly with foreach
}

Why use "collection as IEnumerable"? If it's supposed to be a
collection just use a cast. What would be a reasonable behaviour if
collection is not IEnumerable?

I've used exactly that approach in a reflection-based data mapping
framework where the behaviour was "if this property is a collection,
iterate and process its members".

--
Steve Walker

[Helge Jensen]

Tim Haughton wrote:

Reasonable behaviour is entirely dependent on its context. It's just a code
snippet so reasonable behaviour doesn't really come into it.
Well, sortof... often there is no reasonable alternative behaviour.

Whether to use "as" of (cast) depends on what behaviour should happen if
collection is not IEnumerable. If you expect the object to actually be
IEnumerable, use a cast. If you have some alternate action if it is not
IEnumerable, as is a very viable option for dispatch.

The must usefull use of as that i've seen if in Equals:

public override bool Equals(object o) {
Foo other = o as Foo;
if ( other == null )
return other;
// continue compare
}

or when you already know that the as conversion will yield non-null:

if ( x is Foo )
(x as Foo).f();
else if ( x is Bar )
(x as Bar).f();
...
C Style casting uses the castclass opcode which, as you know, throws an
exception if the type atop the stack is not of the desired type. The as
operator uses the isinst opcode instead, returning a null reference in the
event of the type atop the stack not being of the desired types.
How does the IL code come into consideration? This is about semantics.
There are other considerations of course - the as operator can't use
conversion operators, whereas the C style cast can. The C style cast is
slower than the as operator in success scenarios, and *much* slower than the
as operator in failure scenarios.
Slower? have you done any tests?

I have a test that shows almost exactly the same performance of the two
casts when successfull, with a *slight* edge to casting (less than 2%).

Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration.

The semantics of operations is vastly more important that the
performance, atleast untill performance becomes a problem.

I have a saying i repeat when someone brings this, or foreach vs.
for+index or something other like that up:
"Syntax rarely change performance, but often changes correctness" ;)
I guess the best place for the C style cast is when failure would indicate
an exceptional circumstance.

Yes, but I formulate that the other way around, "rather CastException
now than unexpected behaviour or NullException later". Of course, if you
really *can* do something with the object, even if it's not of the
expected type, using as is fine (and proper).

What I don't want to see is code like:

void f(object x) {
Foo y = x as y;
y.f();
}

Which discards the very usefull info that infact x was not convertible
to y, and instead generates a NullException.

or, the programmer who have heard "as" performs better than casting:

void f(object x) {
Foo y = x as y;
if ( y == null )
throw new SomeException()
}

or, even worse, the surprising semantics of
"default-do-nothing-to-be-flexible"

void f(object x) {
Foo y = x as y;
if ( y != null ) {
// fine and dandy, operations
...
} else {
// What can we do here? ignore
}
}

Which I have seen a few times. This clearly shows a spot where a cast
should have been used. Now, a callers type-mistake is silently ignored!

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Tim Haughton]

"Helge Jensen" <he**********@slog.dk> wrote in message
news:ep**************@TK2MSFTNGP15.phx.gbl...

There are other considerations of course - the as operator can't use
conversion operators, whereas the C style cast can. The C style cast is
slower than the as operator in success scenarios, and *much* slower than the as operator in failure scenarios.
Slower? have you done any tests?

Like I'd have the time ;)

I'm of course relying on Microsoft's recomendations. I'm fairly sure they
tested it.
I have a test that shows almost exactly the same performance of the two
casts when successfull, with a *slight* edge to casting (less than 2%).

Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration.

The semantics of operations is vastly more important that the
performance, atleast untill performance becomes a problem.

I whole heartedly agree.

[snip]

Your other comments regarding exceptions, casting and so on are fine in the
scope of general object oriented development. And I'll almost always rather
my code express intent than be super optimised. But your original question
was "Why use "collection as IEnumerable"? ", a question set in the C# arena,
and my answer was in the same arena.

Well, using the 'as' operator more clearly expresses intent than C style
casting IMHO. It's also faster than C style casting (according to MS) in
versions 1.0 and 1.1 of the CLR, I haven't checked to see if this is still
the case in 2.0.

In the real world, it doesn't make a huge difference, but hey - you asked :)

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Helge Jensen]

It's also faster than C style casting (according to MS) in
versions 1.0 and 1.1 of the CLR, I haven't checked to see if this is still
the case in 2.0.

In the real world, it doesn't make a huge difference, but hey - you asked :)

Real-world performance is meaured in the real-world, not in
MS-recomendations :)

under .NET-1.1:

count: 100000000, as : 00:00:02.5136144, cast: 00:00:02.4435136,
slower: -2,79 %
count: 1000000000, as : 00:00:25.0760576, cast: 00:00:24.2949344,
slower: -3,12 %
Press ENTER

namespace cast_test
{
public class CastTest
{
class Foo {};
class Bar: Foo {}
class Baz: Foo {};
object[] copyfrom = { new Bar(), new Baz() };
object[] copyto = { null, null };
public void test(int count)
{
// Ready for test
DateTime start_as = DateTime.Now;
for ( int i = 0; i < count; ++i )
copyto[i%2] = copyfrom[i%2] as Foo;
DateTime end_as = DateTime.Now;
for ( int i = 0; i < count; ++i )
copyto[i%2] = (Foo)copyfrom[i%2];
DateTime end_cast = DateTime.Now;

TimeSpan time_as = end_as - start_as;
TimeSpan time_cast = end_cast - end_as;
TimeSpan cast_slower = time_cast - time_as;

Console.WriteLine("count: {0}, as : {1}, cast: {2}, slower:
{3:p}", count, time_as, time_cast, cast_slower.TotalMilliseconds /
time_as.TotalMilliseconds);
}
public static void Main()
{
CastTest t = new CastTest();
int[] counts = { 100000000, 1000000000 };
foreach ( int count in counts )
t.test(count);
bool readline = !System.Diagnostics.Debugger.IsAttached;
#if !DEBUG
readline = true;
#endif
if ( readline )
{
Console.WriteLine("Press ENTER");
Console.Read();
}
}
}
}
--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Oliver Sturm]

Helge Jensen wrote:

It's also faster than C style casting (according to MS) in
versions 1.0 and 1.1 of the CLR, I haven't checked to see if this is still
the case in 2.0.

In the real world, it doesn't make a huge difference, but hey - you asked
:)

Real-world performance is meaured in the real-world, not in
MS-recomendations :)

under .NET-1.1:

count: 100000000, as : 00:00:02.5136144, cast: 00:00:02.4435136, slower:
-2,79 %
count: 1000000000, as : 00:00:25.0760576, cast: 00:00:24.2949344, slower:
-3,12 %

I don't know about MS saying that "as" is faster - I think both "as" and
casts have their practical use and I would have assumed casts to be
faster, simply because they have less to do.

If I know an object to be of the type I want it to be, only due to the
flow of things I don't have a reference of that type at the moment, I use
a cast to get that reference. But if I'm not sure whether an object has
the type (or implements the interface) I'm looking for, I have to find
out, and there are two ways of doing that: (1) using "is", followed by a
cast and (2) using "as" and compare to null - AFAIK (2) is a lot faster
here, and it's also cleaner to read. Small wonder it should be a bit
slower than the cast alone; after all, you get the same functionality that
the "is + cast" combination offers.

As I was saying, I don't usually use casts all that much. Normally, when I
know an object to be of a specific type, I'll probably already have a
reference of that specific type, so I don't need to cast one. This sounds
like part of the discussion "coding to an interface vs. coding to an
implementation" to me - if you find yourself doing casts all the time,
maybe you should ask yourself why you're passing around interfaces (in the
general, not the C# sense of the word) but apparently writing a lot of
code that's implementation specific. Using "as" here and there to code
optional behaviour, especially when dealing with interfaces (in the C#
sense of the word this time), sounds like a much better idea to me.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Helge Jensen]

Oliver Sturm wrote:

Helge Jensen wrote: I don't know about MS saying that "as" is faster - I think both "as" and
casts have their practical use and I would have assumed casts to be
faster, simply because they have less to do.
Perhaps you confused my post with Tim's? I explicitly said:

"Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration. "

I am not really interested in discussed if X is faster than Y, but I am
provoked by statements like "X is faster than Y, so I use X". Especially
when I know the two to be semanticly different and the performance
difference to be neglicible.
find out, and there are two ways of doing that: (1) using "is", followed
by a cast and (2) using "as" and compare to null - AFAIK (2) is a lot
faster here, and it's also cleaner to read. Small wonder it should be a
bit slower than the cast alone; after all, you get the same
functionality that the "is + cast" combination offers.
I still (slightly) prefer writing type-dispatch as:

if ( x is Foo )
(x as Foo).f();
else if ...

Since it reads easier than:

if ( x is Foo )
((Foo)x).f();
else if ...

I don't think i have a single place where I will notice (if there is
one, the compiler could easily rewrite one to the other) performance
difference.
This
sounds like part of the discussion "coding to an interface vs. coding to
an implementation" to me - if you find yourself doing casts all the
time, maybe you should ask yourself why you're passing around interfaces
(in the general, not the C# sense of the word) but apparently writing a
lot of code that's implementation specific. Using "as" here and there to
code optional behaviour, especially when dealing with interfaces (in the
C# sense of the word this time), sounds like a much better idea to me.

I don't think anyone was talking about casting "all the time", I ain't
anyway.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Oliver Sturm]

Helge Jensen wrote:

I don't know about MS saying that "as" is faster - I think both "as" and
casts have their practical use and I would have assumed casts to be
faster, simply because they have less to do.

Perhaps you confused my post with Tim's? I explicitly said:

"Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration. "

I am not really interested in discussed if X is faster than Y, but I am
provoked by statements like "X is faster than Y, so I use X". Especially
when I know the two to be semanticly different and the performance
difference to be neglicible.

Sorry, I was more or less commenting on the complete discussion lead by
you two.

find out, and there are two ways of doing that: (1) using "is", followed
by a cast and (2) using "as" and compare to null - AFAIK (2) is a lot
faster here, and it's also cleaner to read. Small wonder it should be a
bit slower than the cast alone; after all, you get the same functionality
that the "is + cast" combination offers.

I still (slightly) prefer writing type-dispatch as:

if ( x is Foo )
(x as Foo).f();
else if ...

Since it reads easier than:

if ( x is Foo )
((Foo)x).f();
else if ...

And I'll use this form, which I find even more readable and which is
probably the most performant at the same time:

Foo foo = x as Foo;
if (foo != null)
foo.f();
...

Which was really the starting point of the whole discussion, wasn't it?
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Joanna Carter \(TeamB\)]

"Marco" <te******@yahoo.com> a écrit dans le message de news:
11**********************@g44g2000cwa.googlegroups. com...

I need to get a iterator from any generic collection.
public class .... GetIterator(Object collection)
{

....

}

How can I do this with reflection?

You shouldn't need reflection, just check if the object supports IEnumerable
and then cast it to IEnumerable and call GetEnumerator.

Joanna

--
Joanna Carter
Consultant Software Engineer