Pointer Handling

Topics: General, VB Language Design
May 11, 2014 at 5:18 PM
Hi,
I want to give an idea of something advanced
    Sub Abc()
        Cde(True)
    End Sub
    Sub Cde(x As Boolean)
        If x Then
            Exit CallerSub
        Else
            Exit Sub
        End If
    End Sub
In current we cannot do that
we have do do that:-
    Sub Abc()
        Dim y = Cde(True)
        If y Then
            Exit Sub
        End If
    End Sub
    Function Cde(x As Boolean) As Boolean
        Return x
    End Function
Is it possible to implement such concepts
I have some of suggestions:=
It can be solved by introducing a keyword as MethodInstance
    Sub Abc()
        Cde(True)
    End Sub
    Sub Cde(x As Boolean)
        'MethodInstance is keyword like Me and MyClass
        If x Then
            MethodInstance.Caller.Exit()
        End If
    End Sub
Similarly if possible to do for Goto
    Sub Abc()
        Dim x = True
10:
        If x Then
            Cde(True)
        Else
            x = False
        End If
    End Sub
    Sub Cde(x As Boolean)
        If x Then
            'MyMethod may be keyword
            MyMethod.Caller.Goto(10)
        End If
    End Sub
May 11, 2014 at 6:28 PM
This would be a very bad thing to do. A method should not influence it's callers control flow directly. That makes it incredibly hard to understand and reason about what can happen in the calling method, without knowing exactly how the methods it calls are implemented.

The most usual way to do this is to use a return a value and let the calling method decide what to do depending on this return value. Is you have an 'Exceptional' situation in which you want to abandon multiple called methods at once, that's where Exceptions are for.

As the Goto statement is generally considered harmful, introducing a 'special' Goto to intervene with the callers control flow would be about the very worst thing I could imagine.
May 12, 2014 at 1:36 AM
Agreed, @FrankBakker
May 12, 2014 at 4:13 PM
The usage of separate DoSomething and TryDoingSomething methods stems from a lack of support for what would arguably be the "right" pattern, which would be a means by which a method could indicate that may return with an exception which, if non-null, the caller should either handle or throw. Not only would such a design avoid the overhead of throwing an exception in cases where there was an expected path from the throw to the catch, but it would also help semantically to distinguish the case where Foo calls Bar and Bar throws an ArgumentException exception for reasons that Foo is expecting, versus the case where Bar calls Boz which throws an ArgumentException for reasons that neither Foo nor Bar is expecting.

At present, no such convention exists in .NET or any .NET language that I know of, and I'm not sure how it could easily be added. About the only approach I can think of to add it given the present language infrastructure would be to define an attribute which would be to define an attribute which would say that if a language understands such things, and a call to a specially-tagged method would be enclosed within a catch for certain exceptions, it should substitute a call to some alternative method which returns an exception rather than throwing it, and add the "checking" code at the call site. If that was done, invocation from languages which did not understand the new concept would invoke a method which would throw any exception that was returned, even if the immediate calling code would have been prepared to handle it.
May 12, 2014 at 10:24 PM
supercat wrote:
The usage of separate DoSomething and TryDoingSomething methods stems from a lack of support for what would arguably be the "right" pattern, which would be a means by which a method could indicate that may return with an exception which, if non-null, the caller should either handle or throw. Not only would such a design avoid the overhead of throwing an exception in cases where there was an expected path from the throw to the catch, but it would also help semantically to distinguish the case where Foo calls Bar and Bar throws an ArgumentException exception for reasons that Foo is expecting, versus the case where Bar calls Boz which throws an ArgumentException for reasons that neither Foo nor Bar is expecting.

At present, no such convention exists in .NET or any .NET language that I know of, and I'm not sure how it could easily be added. About the only approach I can think of to add it given the present language infrastructure would be to define an attribute which would be to define an attribute which would say that if a language understands such things, and a call to a specially-tagged method would be enclosed within a catch for certain exceptions, it should substitute a call to some alternative method which returns an exception rather than throwing it, and add the "checking" code at the call site. If that was done, invocation from languages which did not understand the new concept would invoke a method which would throw any exception that was returned, even if the immediate calling code would have been prepared to handle it.
The pattern does exist exactly like you described.

However, if instead of going for boolean status return value and an output parameter with the output vale the BCL had come up with a return type the represented a conditional value it would have been a lot better. But, remember, this was before generics.
May 13, 2014 at 12:17 AM
PauloMorgado wrote:
However, if instead of going for boolean status return value and an output parameter with the output vale the BCL had come up with a return type the represented a conditional value it would have been a lot better. But, remember, this was before generics.
A function that returns a structure Maybe<T> cannot be covariant with respect to T. Proper covariance would require that the structure return a T and use some other mechanism to indicate success or failure.
May 14, 2014 at 8:47 AM
Why it is not good idea
You can have full control over execution
May be goto is not good but
as you know there is a delegate of every
method which represents its instance

This new concept may revolutionize
I sometime use self Call and sometime
Remote call

sometime you call Sub A From it self so to avoid
StackOverflow Exception One may determine
stacks if they are over a limit he can Exit self sub or Root
May 14, 2014 at 9:19 AM
supercat wrote:
PauloMorgado wrote:
However, if instead of going for boolean status return value and an output parameter with the output vale the BCL had come up with a return type the represented a conditional value it would have been a lot better. But, remember, this was before generics.
A function that returns a structure Maybe<T> cannot be covariant with respect to T. Proper covariance would require that the structure return a T and use some other mechanism to indicate success or failure.
Indeed!