What is pros and cons of calling procedures in VB.NET?
Asked Answered
P

6

6

I would like to know the pros and cons of calling procedures with Call Keyword and without Call in VB.NET?

Private Sub ProOne()
     ' Code Are Here
End Sub

Private Sub Calling()
   ProOne()           ' I would like to know pros and cons of this
   Call ProOne()      ' And I would like to know pros and cons of this
End Sub

Thanks in advance all.

Peephole answered 4/12, 2009 at 16:28 Comment(0)
S
11

From here:

You normally use the Call statement to call a procedure that does not return a value. If the procedure returns a value, the Call statement discards it.

You are not required to use the Call statement when calling a procedure. However, it improves the readability of your code.

So, in essence, ProOne() and Call ProOne() are semantically equivalent.

Sumptuary answered 4/12, 2009 at 16:33 Comment(0)
M
13

There are no pros, and there are no cons.

The Call keyword is a legacy keyword from older VB dialects.

In VB.net it has no meaning, and is syntatic sugar.

Maribeth answered 4/12, 2009 at 16:32 Comment(0)
S
11

From here:

You normally use the Call statement to call a procedure that does not return a value. If the procedure returns a value, the Call statement discards it.

You are not required to use the Call statement when calling a procedure. However, it improves the readability of your code.

So, in essence, ProOne() and Call ProOne() are semantically equivalent.

Sumptuary answered 4/12, 2009 at 16:33 Comment(0)
M
7

One interesting use I found (R# suggested), was when you need to create an instance just to call a single method and then mark it for garbage collection.
Not sure if I'm keeping it though.

For example

Call (new MyType()).MySub()

equivalent of

dim anInstance = new MyType
anInstance.MySub
Marvellamarvellous answered 11/4, 2012 at 15:33 Comment(7)
Wouldn't using the default instance be more succinct? i.e just MyType.MySub()Campinas
@Michael, that suggests you would use a static method. The method isn't static. I think VB allows this indeed, but it is rather confusing. Definitely when you come from a C# bgnd.Marvellamarvellous
@BorisCallens If you're not passing anything to the constructor I don't see how instantiating a new instance is any less confusing than just using the default instance.Dalessio
@BorisCallens In any case, Call is unnecessary. You could just write (new MyType()).MySub()Dalessio
@Dan in VB you can't. Or at least you couldn't (note the timestamp of the post). Working in C# now so haven't tried it lately.Marvellamarvellous
@BorisCallens You're right, apparently an open parenthesis at the beginning of a line is a syntax error.Dalessio
The hack I've always relied on has been DirectCast(new MyType(), MyType).MySub(). Call does seem like a cleaner alternative.Navigation
V
3

Although they are technically equivalent, I would argue against using "Call". When moving from VB6 to VB.Net, it's important to realizae that they are completely different languages that have to be written for in completely different ways. Unfortunately, Microsoft wanted to provide support for VB6 developers, and they provided this by adding functionality that mimics the VB6 functionality, but is siginificantly inferior to the .Net equivalent.

Cutting all ties with any of the VB6 holdovers will make developers stop using these bits as quickly as possible, and lead to better code output.

Vertebra answered 4/12, 2009 at 16:41 Comment(1)
While I agree with you, I can't see why anyone willing to cut all ties wouldn't just use C# instead of VB.NET. Familiarity of syntax is pretty much the only thing VB.NET has going for it.Dalessio
U
2

From documentation

Transfers control to a Function, Sub, or dynamic-link library (DLL) procedure. [ Call ] procedureName [ (argumentList) ]

so,

You normally use the Call statement to call a procedure that does not return a value. If the procedure returns a value, the Call statement discards it.

You are not required to use the Call statement when calling a procedure. However, it improves the readability of your code.

Upholstery answered 4/12, 2009 at 16:33 Comment(1)
"However, it improves the readability of your code". Depends on personal taste, I can't abide it myself and never use it :)Maribeth
T
0

The Call statement still has relevance, even in 2019: "You typically use the Call keyword when the called expression doesn’t start with an identifier. Use of the Call keyword for other uses isn’t recommended."

Call Statement (Visual Basic)

MSDN code sample:

Sub TestCall()
    Call (Sub() Console.Write("Hello"))()

    Call New TheClass().ShowText()
End Sub

Class TheClass
    Public Sub ShowText()
        Console.Write(" World")
    End Sub
End Class
Tadashi answered 3/4, 2019 at 20:35 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.