a vb syntax peculiarity

[Guest]

In the example below, the indicated line yields a syntax error. If the
phrase 'New Test1' appears where an expression is expected, it seems to work
ok. But if it appears where a statement is expected, it does not work. Why
does vb syntax have this peculiar asymmetry? Please no comments about the
foolishness of the code, it just minimally illustrates my question. Also,
the issue poses no inconvenience - I am just curious.

Public Class test1
Public Sub sub1(ByVal i As Integer)
End Sub
Public Function func1(ByVal i As Integer) As Integer
End Function
Public Shared Sub driver()
Dim t As New test1
Dim i As Integer
i = t.func1(i)
i = (New test1).func1(i) ' this compiles ok
t.sub1(i)
(New test1).sub1(i) ' syntax error on this line
End Sub
End Class

 

[tommaso.gastaldi]

In the example below, the indicated line yields a syntax error. If the
phrase 'New Test1' appears where an expression is expected, it seems to work
ok. But if it appears where a statement is expected, it does not work. Why
does vb syntax have this peculiar asymmetry? Please no comments about the
foolishness of the code, it just minimally illustrates my question. Also,
the issue poses no inconvenience - I am just curious.

Public Class test1
Public Sub sub1(ByVal i As Integer)
End Sub
Public Function func1(ByVal i As Integer) As Integer
End Function
Public Shared Sub driver()
Dim t As New test1
Dim i As Integer
i = t.func1(i)
i = (New test1).func1(i) ' this compiles ok
t.sub1(i)
(New test1).sub1(i) ' syntax error on this line
End Sub
End Class

probably it's more clear if you write

i = (New test1).sub1(i) '

problem is that a sub does not produce a value, while a function does.

Seems a logic behavior.

T

 

[Rory Becker]

Try adding the "Call" keyword on the left

Thus:

 

[Herfried K. Wagner [MVP]]

Try adding the "Call" keyword on the left

Thus:

This will work and it's the only case in which 'Call' is still mandatory.

 

[Stephany Young]

Thanks for raising that issue. It had perplexed me as well.

Rory's 'Call' certainly works.

However ....

There is a gotcha that could (not necessarily will) bite you on the bum.

Once the last line of Sub driver has been executed but the exit has not
ocurred, you have 3 instances of text1. 1 is referenced by the variable t
but the 2 others are what I call 'orphaned'.

Even if you you want to, you cannot explicitly dispose of the 2 orphaned
instances.

Under normal circumstances this is not an issue because they will go out of
scope when the method exit is taken and become available to the garbage
collector.

If, however, the object in questions chews a large amount of memory and/or
uses unmanaged resources and/or a lot of use is made of the technique within
a method then there is the potential for a 'memory leak' and or an
OutOfmemory exception.

I'm not saying that one shouldn't use the technique (which is very useful),
rather I am recommending caution as to which objects it is used on and how
much it is used in a given scope.

This is similar to the orphaned implicit object problem in COM Interop
where, for example, an instance of Excel won't go way because of orphaned
implicit objects which cannot be explicitly released.

 

[Guest]

Thanks Rory and Herfried. I guess the call statement gives vb compiler
enough context to proceed.

 

[Guest]

I agree with all you have said, but you go beyond my original question which
was just about when a syntax error occurs at compile time.