Thread: ByRef Vs Properties in web service

Hello to all.

A simple question... more for curiosity.

There are any advantages of using properties vs byref?

Where i can read more for properties VS byref?

Thanks in advance.

Eh? Properties and ByRef are completely un-related really. Properties are used to encapsulate fields in a class and in some cases provide an opportunity to do some additional processing before the property is 'LET'
Properties should never be allowed to be passed by reference. This isn't C programming and pointers don't exist in VB.Net. What are you confused about here, how, when, and why to pass memory BY REFERENCE or using the property block?

Ok.. sorry i don't explain right.

For example;
from a Windowsforms i can use both subs from a class Hello.vb ...

Code:

Public Sub Hello(ByVal name As String, byref answer as string)
        answer = String.Format("Hello {0}.", name)
End Sub

I can get the answer by byref.

Or

Code:

 
Public Sub Hello(ByVal name As String)
        myAnswer = String.Format("Hello {0}.", name)
End Sub

Private myAnswer As String
Public Property Answer() As String
        Get
            Return myanswer
        End Get
        Set(ByVal value As String)
            myAnswer = value
        End Set
End Property

I can use the property.

Any advantage using properties?

Thanks.

Ok, well properties are a bit more .Net if you like. But moving memory is much faster than copying it. So the ByRef sub routine 'should' run faster.But in .Net i wouldn't like to swear that it would. In short, steer clear of ByRef and use properties if you want to access a classes fields. ByRef can be a bit funny if used improperly.

And how i explain that to the boss LOL.

Help if a say the "this" code will be used in webservices..?

Thanks for your opinion.

Code:

 
Public Sub Hello(ByVal name As String)
        myAnswer = String.Format("Hello {0}.", name)
End Sub

Private myAnswer As String
Public Property Answer() As String
        Get
            Return myanswer
        End Get
        Set(ByVal value As String)
            myAnswer = value
        End Set
End Property

Actually in the code above you are not using the property anyway you are directly accessing the field. In .Net 99% of the time you will pass things byval but pass things byref without knowing it. Check out some articles on encapsulation.

I didn't put all the code

WindowsForm

Code:

 Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

        Dim helloRes As New Hello()

        helloRes.Hello("XPTO")

        MessageBox.Show(helloRes.Answer)

    End Sub

Hello.vb

Code:

Public Class Hello

    Public Sub New()

    End Sub

    Public Sub Hello(ByVal name As String)
        myAnswer = String.Format("Hello {0}.", name)
    End Sub

    Private myAnswer As String
    Public Property Answer() As String
        Get
            Return myAnswer
        End Get
        Set(ByVal value As String)
            myAnswer = value
        End Set
    End Property
End Class

Now i use the property


Thanks, i will read about encapsulation.

One more time thanks.

Youre still talking, pretty much, about two different things.

ByRef is a very C++ way of doing things. We dont really do that in C# or VB



Properties are usually for controlling access to variables, or requiring conditions be met for their assignment. Typically you expose properties for other programmers to use.

If you have an attribute of a class that is an integer, and you really must not have that integer set to 0, then you would use a property:

Code:

    Private myInt As Int
    Public Property TheNumber() As Integer
        Get
            Return myInt
        End Get
        Set(ByVal value As String)
            If value = 0 Then Throw New Exception("This property must never be set to zero")
            myInt = value
        End Set
    End Property

Any programmer attempting to use your class and set this incorrectly, will encounter an error.

This kind of control is very hard to implement any other way. You cannot do this by just making myInt public, because then anyone can change it to anything


Additional uses of properties are to mask the way data is stored. You might have all your strings in one array ut want them to appear like sepaarate things. Each property would point to one location in the array

-

The concept of why you would pass something ByRef and why use Properties are very far removed from each other like vis said.. Its hard for me (who knows the difference) to even begin to imagine why you think they are related or should be used for the same thing..

If you want a sub to return a value, make it a function. If you want a function to return several values, make a special class to hold them. Dont use byref.

Use properties to control access to, and facade storage of your classes internal variables.

I didn't use byref...

If you want a function to return several values, make a special class to hold them. Dont use byref.

I was assign to review all webservices/webmethods from my company... and last developer define this

Code:

public function Hello(byval name as string, byref secondName as string, byref lastName as string) as boolean

I find so strange that i had to put here the question

i was thinks to change to

Code:

public sub Hello(byval name as string)

Properties:
SecondName as string
LastName as string
Sucess as boolean

I believe that this make more sense...

Thanks.

When to use a function: when returning a single distinct value. Example: a simple function that adds two numbers.

When to use by Ref "output" parameters: When returning multiple distinct values, that do not need to be stored by the class once the function/sub returns. Example: A function that splits a full name into FirstName and LastName

When to use Properties: When the results of a function/sub needs to be stored for further use by the instance of the class. Example: Loading a Customer class with data from the database.

Caveat: Object items by nature are pointers to the data, and so are always passed by ref.

But alot of this is subjective.

-tg

Webservices don't have properties. When I tested locally Byref worked, but generally you return results as function method, not sub method. If you want to return several data you can define a custom class in webservice and return instances of this.

Btw, the difference of ByVal and ByRef is only significant when dealing with value-type variables, for reference-type variables you will still operate on the same object even if the pointer references are copies. (Edit: ... that is, usually, for web service the reference is "broken". Use function return.)

Thanks you guys for yours posts.

I believe that found the best solution to my project.

If you want to return several data you can define a custom class in webservice and return instances of this.

Realy, have a function that return an instance of a response custom Class. It is the best solution for my project.

Well, in 99% of situations.

One more time, thanks very much for your time and posts.

P.S
In future i will put here a small example of what we are talking about.. to help others.

Originally Posted by JohnH

[with ByVal and ByRef [for reference types] you will still operate on the same object even if the pointer references are copies

Remembering, of course, that the most significant thing being that if you change the object that a ByReffed variable points to, the change is retained when the function completes..

(I felt that john's post was implying there was little difference between byref and byval, and it didnt mention this crucial point. I have no doubt in my mind that JohnH already knows this.. )



In contrast to TechGnome's post, I really wouldnt use ByRef to return multiple different values from a function; I would still always seek a way to encapsulate related data in a class, and if a function did several different things to data so disparate that it wouldnt make sense to encapsulate it, I would question whether it would make sense to have one function to do all that manipulation.

A typical exception to this is typically found in the code the designer generates for accessing the database directly on a multiple parameter SQL statement or stored procedure. One of the overloads of the Insert/Update/Delete commands will have all the parameters passed ByRef, so that any changes the stored procedure made to the data, would be retained. In one sense this is excusable because of the crossing of process boundaries, into a system (t-sql, pl/sql etc) that typically makes more use of "ByRef" style argument passing.. It would still be technically possible to return a data row containing all changed values, it just seems that the ByRef way is used to keep consistency with the other system,. If I were writing my own DAL, I would endeavour to keep to a more modern OO encapsulated mode of operation, and write a function that returned a datarow, with no ByReffed arguments.

As with anything, it's largely personal preference, with the emphasis being on solid justification if questioned as to why a particular route was chosen

Originally Posted by cjard

Remembering, of course, that the most significant thing being that if you change the object that a ByReffed variable points to, the change is retained when the function completes..

As I said, that is only valid if the variable is value type, a reference type variable is reference to same object even when there are multiple copies of the reference. Using ByVal parameter on a reference variable just creates a new copy of the reference to the same object. This simple example show this:

Code:

    Class test
        Public member As String
    End Class
 
    Sub maketest()
        Dim t As New test
        t.member = "new"
        modifytest(t)
        MsgBox(t.member) 'guess what? t object is changed.
    End Sub
 
    Sub modifytest(ByVal t As test)
        t.member = "modified"
    End Sub

Yes, of course.. With ByVal and ByRef, it is the pointer that is copied.. In either case, as JohnH said, the data it points to is the same, and manipulation of that data object is retained..

The crucial differnce is that if you swap it out for a whole new object, then the ByRef one repoints the original. This can be dangerous, and generally not needed/recommended unless one knows exactly why the behaviour occurs and does it intentionally

Code:

    Class test
        Public member As String
    End Class
 
    Sub maketest()
        Dim t As New test
        t.member = "the original test"
        modifytest(t)
        MsgBox(t.member) 't object is replaced by a whole new one!
    End Sub
 
    Sub modifytest(ByRef tt As test)
        tt = New test()
        tt.member = "a whole new test"
    End Sub

If the modifytest function was ByVal, then t would still point to "original test" and the whole new test is lost, because we changed a copy of the pointer.
If the modifytest function is ByRef, then t points to "a whole new test" and the original is lost, because we never made a copy of the pointer

Thus, there is a difference between ByRef and ByVal. As John says, in either case, if you mutate the object itself, the changes are retained.. The difference comes if you replace the object with a whole new one.. Doing so is generally regarded as bad OO practice, so we dont do it.


Maybe my original sentence didnt get my point across clearly.. I hope this helps!

Originally Posted by cjard

In contrast to TechGnome's post, I really wouldnt use ByRef to return multiple different values from a function; I would still always seek a way to encapsulate related data in a class, and if a function did several different things to data so disparate that it wouldnt make sense to encapsulate it, I would question whether it would make sense to have one function to do all that manipulation.

True, true.... I was thinking of in terms of how we go about deciding such things here.... forgetting that we are still steeped in VB6 at the moment. Ugh.... I can't wait to move over....

-tg