Re: foreach pretty useless for composite classes, don't ya thunk?

[Bill Butler]

"raylopez99 " <raylopez99@yah oo.comwrote in message
news:bd59f62a-5b54-49e8-9872-ed9aef676049@t5 4g2000hsg.googl egroups.com...
<snip>

>Any thoughts? Or am I right as usual?

I don't think "right" is the correct word.
There are many other words that could fill in the blank though.

"Or am I _______ as usual?"

[raylopez99]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 6:15 am, "Bill Butler" <qwe...@asdf.co mwrote:

"raylopez99 " <raylope...@yah oo.comwrote in message
>
news:bd59f62a-5b54-49e8-9872-ed9aef676049@t5 4g2000hsg.googl egroups.com...
<snip>
>

Any thoughts?  Or am I right as usual?

>
I don't think "right" is the correct word.
There are many other words that could fill in the blank though.
>
    "Or am I _______ as usual?"

Ad homenium attack noted, and you don't have an answer to my question,
which is why do we need foreach.

RL

[Brian Gideon]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 10:05 am, raylopez99 <raylope...@yah oo.comwrote:

Ad homenium attack noted, and you don't have an answer to my question,
which is why do we need foreach.
>

It provides a convenient way of using IEnumerable and IEnumerator
classes.

At first I thought you were asking why someone would bother
implementing their own IEnumerable and IEnumerator classes. There was
also some talk of more than one member variable in classes, etc. Like
I said earlier...can you summarize your point in one concise paragraph
and example?

[raylopez99]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 8:23 am, Brian Gideon <briangid...@ya hoo.comwrote:

On Sep 19, 10:05 am, raylopez99 <raylope...@yah oo.comwrote:
>

Ad homenium attack noted, and you don't have an answer to my question,
which is why do we need foreach.

>
It provides a convenient way of using IEnumerable and IEnumerator
classes.
>
At first I thought you were asking why someone would bother
implementing their own IEnumerable and IEnumerator classes.  

I was.

There was
also some talk of more than one member variable in classes, etc.  

Yes, that was another point.

Like
I said earlier...can you summarize your point in one concise paragraph
and example?

That would be the original post--the observation that IEnmerable (the
interface) and IEnumerator (with implements three methods, namely bool
MoveNext(), object Current {get;} and void Reset();)--is pretty
worthless for anything other than a one-member class.

The program was simply to demonstrate one such useless
implementation. I further observed (and this is from a textbook that
made the same point) that you can simply declare a static IEnumerable
<Tand let the compiler take care of any implementation, rather than
go the IEnumerable/IEnumerator route.

RL

[Brian Gideon]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 1:03 pm, raylopez99 <raylope...@yah oo.comwrote:

On Sep 19, 8:23 am, Brian Gideon <briangid...@ya hoo.comwrote:
>

On Sep 19, 10:05 am, raylopez99 <raylope...@yah oo.comwrote:

>

Ad homenium attack noted, and you don't have an answer to my question,
which is why do we need foreach.

>

It provides a convenient way of using IEnumerable and IEnumerator
classes.

>

At first I thought you were asking why someone would bother
implementing their own IEnumerable and IEnumerator classes.  

>
I was.
>

There was
also some talk of more than one member variable in classes, etc.  

>
Yes, that was another point.
>

 Like
I said earlier...can you summarize your point in one concise paragraph
and example?

>
That would be the original post--the observation that IEnmerable (the
interface) and IEnumerator (with implements three methods, namely bool
MoveNext(), object Current {get;} and void Reset();)--is pretty
worthless for anything other than a one-member class.
>
The program was simply to demonstrate one such useless
implementation.  I further observed (and this is from a textbook that
made the same point) that you can simply declare a static IEnumerable
<Tand let the compiler take care of any implementation, rather than
go the IEnumerable/IEnumerator route.
>
RL

Regarding the first point...you don't necessarily have to do the work
of implementing an IEnumerator now. C# 2.0 added the ability to use
the 'yields' keyword that does this for you. But, that ability hasn't
always existed. So my answer to that question is that most of the
time you probably wouldn't bother doing it manually.

Regarding being able to create an IEnumerable and IEnumerator that
incorporates iterations over more than one member variable...Were you
talking about the case where you want one iteration to cover multiple
class members or different iterations over different class members.
More precisely, are you 1) wanting one iterator to enumerator some
combination of items from more than one variable or 2) be able to
define different iterators that enumerator items from different
variables. It's possible to accomplish either one. In the first case
it is only slightly more complicated than a trivial case. You just
have to come up with the appropriate logic for the MoveNext method (or
the equivalent if using the yields keyword). I've done it before. In
the second case you just add more properties to the class that return
the appropriate IEnumerable classes. Take a look at the Dictionary
class. It has Values and Keys properties that do just that.

And to sum it all up the foreach construct provides an elegant way for
working with IEnumerable and IEnumerator classes. Sure, you can call
the Reset, MoveNext, and Current members yourself in a while loop.
But, why do that when the compiler will do it for you. Plus, foreach
will automatically call Dispose if your IEnumerator just happens to
implement IDisposable as well.

[raylopez99]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 12:08 pm, Brian Gideon <briangid...@ya hoo.comwrote:

>
Regarding being able to create an IEnumerable and IEnumerator that
incorporates iterations over more than one member variable...Were you
talking about the case where you want one iteration to cover multiple
class members or different iterations over different class members.
More precisely, are you 1) wanting one iterator to enumerator some
combination of items from more than one variable or 2) be able to
define different iterators that enumerator items from different
variables.  It's possible to accomplish either one.  In the first case
it is only slightly more complicated than a trivial case.  You just
have to come up with the appropriate logic for the MoveNext method (or
the equivalent if using the yields keyword).  I've done it before.  In
the second case you just add more properties to the class that return
the appropriate IEnumerable classes.  Take a look at the Dictionary
class.  It has Values and Keys properties that do just that.

Thanks Brian--if you have an example "I've done it before" that you
can post without giving away a client's source code or whatever,
please feel free. As for the Dictionary Class, I would not even know
where to find the source code, if it exists in my library somewhere.

You other point about 'yields' hiding IEnumerator is interesting and I
will look into FTM's example again with this in mind.

Cheers,

RL

[Brian Gideon]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 7:42 pm, raylopez99 <raylope...@yah oo.comwrote:

On Sep 19, 12:08 pm, Brian Gideon <briangid...@ya hoo.comwrote:
>
>
>

Regarding being able to create an IEnumerable and IEnumerator that
incorporates iterations over more than one member variable...Were you
talking about the case where you want one iteration to cover multiple
class members or different iterations over different class members.
More precisely, are you 1) wanting one iterator to enumerator some
combination of items from more than one variable or 2) be able to
define different iterators that enumerator items from different
variables.  It's possible to accomplish either one.  In the first case
it is only slightly more complicated than a trivial case.  You just
have to come up with the appropriate logic for the MoveNext method (or
the equivalent if using the yields keyword).  I've done it before.  In
the second case you just add more properties to the class that return
the appropriate IEnumerable classes.  Take a look at the Dictionary
class.  It has Values and Keys properties that do just that.

>
Thanks Brian--if you have an example "I've done it before" that you
can post without giving away a client's source code or whatever,
please feel free.  As for the Dictionary Class, I would not even know
where to find the source code, if it exists in my library somewhere.
>

No need. FTM already posted an example that generates an IEnumerator
that enumerates every combination of first and last names based on two
string arrays (one the holds just first names, and the other holds
just last names). FTM just happen to use the yield keyword method.
It could have been done by manually declaring and implementing the
IEnumerator but that would be more work.

As for the Dictionary I was focused more on the public interface and
not necessary on how Microsoft made that happen. I just wanted to
present an example design pattern for case #2. Fortunately, Microsoft
has made the source code for v3.5 of the framework available. I'm not
sure about the details for downloading it as I have yet to do that,
but it is available nevertheless. Of course, you could always use
Reflector or even ILDASM to examine the framework assemblies. The
Dictionary class is either in mscorlib.dll or System.dll.

You other point about 'yields' hiding IEnumerator is interesting and I
will look into FTM's example again with this in mind.
>

Typo...I meant the 'yield' keyword. You used it in the example of the
GetEventInts in your original post. Again use Reflector or ILDASM to
see what the compiler did for you.

[raylopez99]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 19, 7:13 pm, Brian Gideon <briangid...@ya hoo.comwrote:

>
No need.  FTM already posted an example that generates an IEnumerator
that enumerates every combination of first and last names based on two
string arrays (one the holds just first names, and the other holds
just last names).  FTM just happen to use the yield keyword method.
It could have been done by manually declaring and implementing the
IEnumerator but that would be more work.

It also raises the point of the OP--what's the point of
'foreach' (other than eye candy and one somewhat important point)? So
"yield" keyword avoids the awkward IEnumerator inheritance, which I
kind of like, analogous to how delegates are now easier to register
(using 'new') in C#2.0 syntax and/or you don't need to invoke
delegates using .Invoke method--big deal. The "one somewhat important
point" is the one you made: using 'foreach' you can (I think my lingo
is right) do "delayed execution" and/or "lazy execution / evaluation"
and/or you don't need to set up a temporary collection class but can
serially iterate through a collection and get results now, rather than
iterate, get results, store, then output. Fine, that's great and I
agree 'foreach' is great for that. But it's not a big deal IMO* and a
lot of work to get the syntax right.

>
As for the Dictionary I was focused more on the public interface and
not necessary on how Microsoft made that happen.  I just wanted to
present an example design pattern for case #2.  Fortunately, Microsoft
has made the source code for v3.5 of the framework available.  I'm not
sure about the details for downloading it as I have yet to do that,
but it is available nevertheless.  

Well that's pretty worthless "it's out there"--but not to worry, I
have no intention of going through the code anyway, which is probably
understandable only to the author and an expert with years of C# under
their belt. I have about 2 months C# experience (more with C++) as a
hobbyist, and my goal is to get to the 80% competency level, which I
think I'm there, rather than get into minutiae. Like learning a
language, I want to be conversant in C#, not fluent or to teach the
rules of grammar at university.

Of course, you could always use
Reflector or even ILDASM to examine the framework assemblies.  The
Dictionary class is either in mscorlib.dll or System.dll.

Yeah I notice these .dlls are always popular and have a lot of stuff
in them.

Thanks for your help, it was helpful.

RL

* In other posts I've argued that delegates are a lot of work for the
little they give you, and that inheritance is rarely used by practical
coders in OOP --both of these observations being the exceptions--that
prove the rule--for library code, meaning that for library code indeed
you use delegates and inheritance a lot. I made these observations
before I really knew much about delegates and inheritance, now that I
know a lot more, I see my initial hunch was largely right--though,
that said, I like to use inheritance and delegates in my code because
it's kind of cool (delegates are a sophisticated 'GOTO' statement;
inheritance is another form of nesting/hiding) and it keeps your
skills sharp to use these constructs once in a while so you don't
forget the syntax. I'm sure the same is also true for LINQ, which I
see as a poor man's SQL.

[Brian Gideon]

Re: foreach pretty useless for composite classes, don't ya thunk?

On Sep 20, 5:18 am, raylopez99 <raylope...@yah oo.comwrote:

It also raises the point of the OP--what's the point of
'foreach' (other than eye candy and one somewhat important point)?

Eye candy, syntactical sugar, etc. It's not absoluately necessarily as
you could call the appropriate methods on the IEnumerable/IEnumerator
manually. But, it definitely makes the code easier to read.

 So
"yield" keyword avoids the awkward IEnumerator inheritance, which I
kind of like, analogous to how delegates are now easier to register
(using 'new') in C#2.0 syntax and/or you don't need to invoke
delegates using .Invoke method--big deal.

Yep, again you could write all of the code for the IEnumerator
manually, but the yield keyword avoids all of that.

 The "one somewhat important
point" is the one you made:  using 'foreach' you can (I think my lingo
is right) do "delayed execution" and/or "lazy execution / evaluation"
and/or you don't need to set up a temporary collection class but can
serially iterate through a collection and get results now, rather than
iterate, get results, store, then output.  Fine, that's great and I
agree 'foreach' is great for that.  But it's not a big deal IMO* and a
lot of work to get the syntax right.

Yep. That was exactly my point. I suspect in most cases it's not a
big deal. In fact, I rarely exit out of a foreach before it has
natually completed, but the option is available. I have used this
technique in the past when I wanted to extract the first element of a
SortedDictionar y.

object first = null;
foreach (object item in mySortedDiction ary.Values)
{
first = item;
exit;
}

SortedDictionar y is implemented as a BST. So to extract the first
element you have to keep traversing left until you find it. The code
above will complete in O(log n) time since the traversal exits out
early.

Note, in version 3.5 of the framework there is the First extension
method that likely uses this method, but I'd have to examine the code
or IL to know for sure.

Well that's pretty worthless "it's out there"--but not to worry, I
have no intention of going through the code anyway, which is probably
understandable only to the author and an expert with years of C# under
their belt. I have about 2 months C# experience (more with C++) as a
hobbyist, and my goal is to get to the 80% competency level, which I
think I'm there, rather than get into minutiae.  Like learning a
language, I want to be conversant in C#, not fluent or to teach the
rules of grammar at university.
>

You might be surprised. Looking at the framework code is not only a
great way to learn industry standard design patterns, but I think it
would also be helpful in learning syntax and techniques specific to
C#. I really don't think you need to be expert to benefit from
looking at the code.

* In other posts I've argued that delegates are a lot of work for the
little they give you, and that inheritance is rarely used by practical
coders in OOP --both of these observations being the exceptions--that
prove the rule--for library code, meaning that for library code indeed
you use delegates and inheritance a lot.  I made these observations
before I really knew much about delegates and inheritance, now that I
know a lot more, I see my initial hunch was largely right--though,
that said, I like to use inheritance and delegates in my code because
it's kind of cool (delegates are a sophisticated 'GOTO' statement;
inheritance is another form of nesting/hiding) and it keeps your
skills sharp to use these constructs once in a while so you don't
forget the syntax.  I'm sure the same is also true for LINQ, which I
see as a poor man's SQL.

Those are all good topics for other threads.