Yield Keyword in VB.NET 2.0

  • Thread starter Thread starter Sahil Malik [MVP]
  • Start date Start date
Cor Ligthert said:
It runs, you did obvious not try it, it gives as result
0 first
1 first
2 second
3 second
Click to expand...

Yeah, but it has nothing to do with iterators ;-).
 
Cor said:
Frans,

Have a nice day, maybe it is better that you walk to the end of the
'pier' take a deep breath and ask yourself: "Is this the tone I have
to write in a newsgroup".
Click to expand...

err, what's the problem? I just pointed out that what you tried to
explain is something completely different than yield.

Besides that, it's way too hot on the beach now.

FB

--
 
Cor said:
It runs, you did obvious not try it, it gives as result
0 first
1 first
2 second
3 second
Click to expand...

oh due to the if y=2 then break blah. OK, overlooked that one, in my
blindness caused by the Static keyword. I didn't try the code.

I fail to see what it has to illustrate though.
Did I say that, I don't like the static keyword. It is to much
hidden. That is one of the things that Jon Skeet and I very much
agree about.
Click to expand...

I just wanted to explain that code like you wrote is hard to read,
thus not what you want. This was mainly caused by the static keyword.
I.o.w.: static is IMHO a keyword you should better avoid (like goto),
and thus IF iterators would be programmable using static, like you
suggested, it wouldn't be a big win, on the contrary, you'd better opt
for a different approach.

FB

--
 
Herfried,

I only tried to give Sahil an alternative for his 'yield'.

The static is the one that comes in my idea the most near at it.

And than I got reply that was in my opinion about a shared class and his
members.

I am quiet sure that the yield is not exactly the same as a VB static,
otherwise I had given an example with a foreach.

Although in my idea is it not imposible that it will act internal not much
less than a VB static variable. You cannot keep values in memory and in the
same time let them go out of scope.

However that I cannot oversee, and was as well not the meaning of my answer.

Cor
 
Cor,

What the hell are you talking about? Anyway, I got my answer from Mattias.

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
----------------------------------------------------------------------------
 
Cor,

Frans is completely right in this regard. I asked you about yield, you are
telling me about static/shared - seriously are you just trying to get your
post count up?

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
 
Well I did write up an enumerator class myself. It's not a super big deal,
but just annoying that something I could have done in 3 lines of code in VB
requires me to implement another class. Anyway, that is something what is
done behind the scenes by yield anyway - and I beleive it is threadsafe
code, so yield isn't too shabby IMO.

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
 
Cor,

Lets try one more time now -

"I asked about "Yield" and you told me about Static."

Get it?

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
----------------------------------------------------------------------------
 
Cor,

Cor Ligthert said:
I only tried to give Sahil an alternative for his 'yield'.
Click to expand...

As I say, your sample is /not/ an alternative.
The static is the one that comes in my idea the most near at it.
Click to expand...

It doesn't. Take a look at the C# sample I posted in the other reply.
And than I got reply that was in my opinion about a shared class and his
members.

I am quiet sure that the yield is not exactly the same as a VB static,
otherwise I had given an example with a foreach.

Although in my idea is it not imposible that it will act internal not much
less than a VB static variable. You cannot keep values in memory and in
the same time let them go out of scope.
Click to expand...

Static variables in VB.NET won't help much. The trick behind the 'yield' is
that it returns the value to the iterator but doesn't exit the method. This
behavior can be faked using delegates, as mentioned in another reply.
 
Frans Bouma said:
I just wanted to explain that code like you wrote is hard to read,
thus not what you want. This was mainly caused by the static keyword.
I.o.w.: static is IMHO a keyword you should better avoid (like goto),
Click to expand...

I disagree. There are certain cases where 'Static' makes perfect sense and
additionally leads to better-encapsulated code than using a private (shared)
field. Note that this should not encourage the use of 'Static' where it
doesn't make much sense ;-).
 
Maybe a feeble attempt at humor will ligthen things up. My buddy Roland
once gave me this expression and I loved it becuase, well, it's practically
my personal motto "
Doe maar gewoon, dan doe je al gek genoeg"

http://rolandboon.net/WSBeanRSS/Weblog.aspx?day=2004-12-30/1

This is probably a good time for us all to listen to good old Roland ;-)

Also , remind me to tell you about our discussion after the user's group
about business objects.
 
Herfried,

As I said, I have to little information about the yield. I gave my answer as
a maybe equivalent of it.

Where I wrote "I think that this reaches where you are looking for".

The answer on this message was
\\\
I'm not talking about "Static/Shared" .. I am talking about "Yield".
///

This answer could have been as well in a decent way, however it gave me the
idea that the OP did/does (still) not know what static means VB as special
keyword inside a procedure. Therefore I tried to explain it by samples.

You always learns in these newsgroup.

:-))

Cor
 
Herfried,
Cor, try to keep it outside the groups.
Click to expand...
As you know I try forever, however sometimes I get angry when the mud is to
much.
However you are right in this one.

If you look at the last replies from Frans than you see what I tried to
tell.
(The one you have replied now that you disagreed. And do that than because
of that as well with me).
"A real man can admit when he makes a mistake."
Click to expand...
I am not mistaking in this. In my opinion have I nowhere written what you
probably think that you read from the answers from others.

See my other message to your thread written before I could read this one.

Cor
 
Herfried said:
I disagree. There are certain cases where 'Static' makes perfect
sense and additionally leads to better-encapsulated code than using a
private (shared) field. Note that this should not encourage the use
of 'Static' where it doesn't make much sense ;-).
Click to expand...

Now I'm interested in what these situations are. Could you give an
explanation where it will give much BETTER code than when you wouldn't
have the Static keyword?

FB

--
 
Back
Top