Yield Keyword in VB.NET 2.0

  • Thread starter Thread starter Sahil Malik [MVP]
  • Start date Start date
I actually got that phrase from Rolan Boon. I have a LONG way to go
learning Dutch before I make it over there at the end of the year.

Mijn Nederlands is slecht, maar ik denk ik begrijp
What I was hoping to say is that My dutch isn't all that good, but I think I
understood your point.
 
Bill,
Mijn Nederlands is slecht, maar ik denk dat ik het begrijp

If it is not Bablefish than it was very good.

The English meaning of

Het slaat als een tang op een varken

That fits as a flag on a broomstick

:-)

Cor
 
Frans Bouma said:
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?

I never said that it will give /much/ better code! One of the Windows Forms
FAQs is how to execute certain code only the first time a Windows Forms form
is activated. There are many different solutions to the problem which have
different advantages and disadvantages. Sure, you could create a private
field instead of the static variable below, but I think that a static
variable encapsulates the whole functionality more tightly:

\\\
Private Sub Form1_Activated( _
ByVal sender As Object, _
ByVal e As EventArgs _
) Handles MyBase.Activated
Static IsActivated As Boolean
If Not IsActivated Then
IsActivated = True
Application.DoEvents() ' ...
MsgBox("Form activated for the first time!")
End If
End Sub
///

Today's code often suffers from the problem that private variables holding
values used in a method or property semantically belong to a certain method
or property, and /not/ to the whole class. For methods this problem can be
reduced by using static variables. Similar functionality for properties
would be great, for example, something like the code below:

\\\
Public Property TheFoo() As Foo
Dim TheFooValue As Foo
Get
Return TheFooValue
End Get
Set(ByVal Value As Foo)
TheFooValue = Value
End Set
End Property
///

However, this is currently not supported.
 
Sahil,
Static is not an equivalent of Yield.
Now I see it, probably do I not understand the word "Any" (that word that
you wrote and now consequently are changing for "an").

I did not know that in English "any" is an equivalent for "exactly"

While I did not say, "it is". I wrote that I thought ("think" was what I
wrote) that it reached that.

Ah, I see it; "thinking" is probably the same in English as "telling"

Sorry, I assume that is the problem,

Thank you for learning me this

Cor
 
Herfried,
\\\
Private Sub Form1_Activated( _
ByVal sender As Object, _
ByVal e As EventArgs _
) Handles MyBase.Activated
Static IsActivated As Boolean
If Not IsActivated Then
IsActivated = True
Application.DoEvents() ' ...
MsgBox("Form activated for the first time!")
End If
End Sub
///
For me this is BS (not angry meant only for the discussion). I have even
seen that people use for this a tag in a control, because it is always
global, my opinion is than to set it just global. In VB it is that even
shorter to write if you use "Dim" (what I don't do if it is global) than
"Static". The technical result is probably (you know that most probably
better) the same.

Where I have seen static used nice, was where your friend (Fergus) used in
to keep track of the last used mouse pointers inside a procedure. That was
the reason why I direct made a relation to an iterator.

However it is for me something very special in VB. Therefore I don't like
it. I have to search that static variable (I don't expect it as static) and
make than easily the same mistake as Frans made with my sample.

Cor
 
Cor Ligthert said:
For me this is BS (not angry meant only for the discussion). I have even
seen that people use for this a tag in a control, because it is always
global, my opinion is than to set it just global. In VB it is that even
shorter to write if you use "Dim" (what I don't do if it is global) than
"Static". The technical result is probably (you know that most probably
better) the same.

I feel sorry, but I don't have a cue what you are talking about...
 
Herfried said:
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),using a >> private (shared) field. Note that this should not
encourage the use >> of 'Static' where it doesn't make much sense ;-).

I never said that it will give much better code! One of the Windows
Forms FAQs is how to execute certain code only the first time a
Windows Forms form is activated. There are many different solutions
to the problem which have different advantages and disadvantages.
Sure, you could create a private field instead of the static variable
below, but I think that a static variable encapsulates the whole
functionality more tightly:

\\\
Private Sub Form1_Activated( _
ByVal sender As Object, _
ByVal e As EventArgs _
) Handles MyBase.Activated
Static IsActivated As Boolean
If Not IsActivated Then
IsActivated = True
Application.DoEvents() ' ...
MsgBox("Form activated for the first time!")
End If
End Sub
///

Though the 'form' is activated so isn't it more appropriate to simply
keep a member variable? After all, the data of the activation of the
form belongs to the form, at least that's my understanding, but that's
nittpicking about the example. I think in a more procedural
environment, where the code is stored in a class but you want to run
the code just one time, not multiple times, and the code can;t really
rely on the class it is in as the class is just a container of the
code, it might make sense, but IMHO those situations are pretty rare
(as in: in an OO world, you can always write the code differently so
you dont' need it)
Today's code often suffers from the problem that private variables
holding values used in a method or property semantically belong to a
certain method or property, and not to the whole class. For methods
this problem can be reduced by using static variables. Similar
functionality for properties would be great, for example, something
like the code below:

\\\
Public Property TheFoo() As Foo
Dim TheFooValue As Foo
Get
Return TheFooValue
End Get
Set(ByVal Value As Foo)
TheFooValue = Value
End Set
End Property
///

However, this is currently not supported.

and rightfully so. properties belong to the semantic unit represented
by the class to set/get class related (private) fields. All code in a
class is there because it is behavior belonging to the type(s) the
class represents and to serve the data the class holds. It requires
that procedural thinking should take a backseat. Personally I can't
think of a situation where local scoped data has to be stored in a
class member because the method ends and it's semantically wrong to
place the data in a variable outside the method.

FB

--
 
Frans,

For me it is simple where my problem with static is.

"A value goes out of scope, when it is instanced inside a procedure and
there is not a reference from another object to it, when the program leaves
the procedure".

The static keyword is for me in conflict with that and because that I find
that rule so important gives it me not the right feeling.

Of course is every code allowed, OOP is for me just a method to make it
clearer and therefore for me the way to go. In addition, that second
sentence (rule) I wrote is even outside OOP a rule.

Cor.
 
Yall are crazy

Cor Ligthert said:
Herfried,

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).

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
 
Back
Top