Byref New Object. Is it okay top pass New Object as "byref"

Question

Below I tried to do an Example:

Public Function UserData(ByVal UserDN As String) As DataTable
    Dim myTable As DataTable = UserData_Table()
    Dim dr As DataRow

    dr = myTable.NewRow()
    SplitOU2(UserDN, dr("OUDN"), dr("Organisation"), New Object)
    dr("UserDN") = UserDN

    myTable.Rows.Add(dr)

    Return myTable
End Function

Below is the called method:

Friend Sub SplitOU2(ByVal inDN As String, ByRef OUDN As Object, ByRef Organisation As Object, ByRef VerksamhetTyp As Object)

By doing this I can skip to declare the in this example "useless" variable Dim VerksamhetTyp as Object = "".

Perhaps it looks a little ugly but to have to declare unused variables can also be confusing.

Answer 1

Summary: Check whether or not the method really needs those parameters to be ByRef. Also check that you really don't care about anything it does to the parameters. After scrupulous checking, it's okay to do this - nothing "bad" will happen in terms of the CLR, because it's just a compiler trick under the hood.

Well, VB (unlike C#) will let you do this. Behind the scenes it's effectively creating a new variable and passing it by reference - after all, it has to for the method to be called properly. However, I'd say this is usually a bad idea. The point of ByRef is that you use the value after it's been set within the method.

Do you really need all those parameters to be ByRef in the first place? If you find yourself doing this a lot for a particular method, you could always write a wrapper method which called the original one, but didn't have the ByRef parameters itself.

(I usually find that methods with a lot of ByRef parameters indicate either a lack of understanding of reference types in .NET, or that the parameters should be encapsulated in their own type.)

Having said all of this, it's not always incorrect to ignore the value of a ByRef argument after calling the method. For example, if you just want to know whether or not some text can be parsed as an integer, then using Int32.TryParse is reasonable - but only the return value is useful to you.

Answer 2

Yes, you can as the code below demonstrates:

    Public Shared Function Show()
        Dim myTable As New DataTable
        myTable.Columns.Add("OUDN")
        myTable.Columns.Add("Organisation")
        Dim dr As DataRow = myTable.NewRow()
        Dim UserDNmyTable As New DataTable
        Dim UserDN As Object = Nothing

        dr = myTable.NewRow()
        SplitOU2(UserDN, dr("OUDN"), dr("Organisation"), New Object)
        dr("UserDN") = UserDN
        myTable.Rows.Add(dr)
        Return myTable

    End Function

    Shared Sub SplitOU2(ByVal a As Object, ByVal b As Object, ByVal c As Object, ByRef d As Object)
        d = "asdf"
    End Sub

The code does not do anything usefull. It's sole purpose is to demonstrate that the copile allows what you are asking for.

If you have control over SplitOU2, I would consider creating an overload that does not take that extra parameter.

Answer 3

The reason that I consider to use this has to do with that the method has even more parameters and that different operation overloads gets the same signature …. The fact that it works is quite fun and somthing I became awarae óff by chance ...