"ref object a" <> "ByRef a As Object" ???

  • Thread starter Thread starter Dr Duck
  • Start date Start date
Cor Ligthert said:
You did change it so much that it almost looks like this sample you showed
me


("out" and "ref" parameters are very similar, I hope you'll agree)

What is wrong with that (however I would not use it only to move a value)
Click to expand...

Nothing. You've snipped the piece of code which is problematic:

Dim data As String = "moo"
Dim f as New Form
bind(f.Text, data, False)

The problem is passing f.Text by reference, as it's a property, not a
variable. It causes the VB.NET compiler to do nasty stuff to add a
temporary local variable, fetch f.Text into it, pass the local variable
by reference, and then set f.Text to the value of the temporary local
variable afterwards. Icky.
 
Hi Jon,

Dim data As String = "moo"
Dim f as New Form
bind(f.Text, data, False)

The problem is passing f.Text by reference, as it's a property, not a
variable. It causes the VB.NET compiler to do nasty stuff to add a
temporary local variable, fetch f.Text into it, pass the local variable
by reference, and then set f.Text to the value of the temporary local
variable afterwards. Icky.
Click to expand...

I saw that of course (not how it is done), but what is wrong with that added
intelligence. The string itself does the same it is immutable, so the
reference should change and that is done as well in VB.net as in C#.

:-)

Cor
 
Cor Ligthert said:
I saw that of course (not how it is done), but what is wrong with
that added intelligence. The string itself does the same it is
immutable, so the reference should change and that is done as well in
VB.net as in C#.
Click to expand...

It's actually got nothing to do with immutability. The reason it's
"wrong" is:

o It involves exactly one "read" of the property and one "write" of the
property - despite the fact that the method may be reading and writing
the parameter several times during its course.

o It hides the fact that it's doing this single read and single write.
If you're forced to do it explicitly, it's much more obvious what's
going on.

o As Dr Duck has said, it could have nasty effects on multi-threaded
scenarios, where one thread *thinks* it has actually set a value, as
it's set the value of a parameter which has been passed by reference.
In actual fact, it's just setting the value of the hidden local
variable. Unless you *know* what's happening, you could get into all
sorts of bother working out why things aren't working.
 
Back
Top