[RESOLVED] Do not use GOTO

Quote:

---

Originally Posted by AdamPanic2013

Shows your lack of knowledge.

---

I'm going to have to take exception to that. I would question whether the code you showed in your screen shot is even being compiled. For a start, what exactly is 'a.__' when it's at home?

Attachment 104215

Even if we get rid of that, we still have the same issue as before.

Attachment 104217

The knowledge that I allegedly lack tells me that the very purpose of Option Strict On is to disallow implicit conversions and late binding. That same knowledge tells me that a < operator is going to evaluate to a Boolean value no matter what, so that code is going to be comparing a Boolean to some other value. That obviously requires an implicit conversion unless that other value is type Boolean. If it's a bit embarrassing to post it here, you can PM me your apology if you like.

I think they are just opening the industry to bad practice since the IDE's still allow the use of "GOTO, etc".

Quote:

---

Originally Posted by Nightwalker83

I think they are just opening the industry to bad practice since the IDE's still allow the use of "GOTO, etc".

---

That's really about backward compatibility. Introducing a breaking change is not something that they do lightly and there has to be very good reason for it. Removing a keyword from the language doesn't actually achieve anything positive in and of itself and could potentially break lots of code that relies on that keyword. Protecting people from themselves by reducing the likelihood of their writing spaghetti code would not be seen as sufficient justification for such a breaking change.

Quote:

---

Originally Posted by AdamPanic2013

Attachment 104213
Shows your lack of knowledge.

It works with any type that implements the IComparable(Of T) interface.

---

Photoshop much ? That does not work.

Quote:

---

Restricts implicit data type conversions to only widening conversions, disallows late binding, and disallows implicit typing that results in an Object type.

---

Why assume Photoshop?

Where does it state that the "comparison" operators must return Boolean? Is possible they can return something else?

Try it out. Doesn't take two minutes to discover, that this assumption is incorrect.

Code:

---

Public Class Eg
  Shared Operator < (ByVal a As Integer, b As Integer) As Eg

  End Operator
End Class

---

So if operators are defined by the type that implements them.
And the a comparison operators aren't activated via IComparable(Of T) interface cos interfaces can't implement static / shared methods.

So you could (and can) define an object (or as in my implementation multiple objects) that lifts the value into a different type where you can implement operators that does bounds checking.


Seeing that you don't believe me here that is possible. Here is the code, that does it.

Code:

---

Public Class PartA(Of T As IComparable(Of T))
  Private _Value As T
  Public Sub New(Value As T)
    _Value = Value
  End Sub
  Public ReadOnly Property Value As T
    Get
      Return _Value
    End Get
  End Property

  Public Shared Widening Operator CType(ByVal Value As T) As PartA(OF T)
    Return New PartA(Of T)(Value)
  End Operator

  Public Shared Operator <(ByVal P As PartA(of T) , Value As T) As PartB(OF T)
    Return New PartB(Of T)( P.Value.CompareTo(Value)<0, Value)
  End Operator
    Public Shared Operator <=(ByVal P As PartA(of T) , Value As T) As PartB(OF T)
    Return New PartB(Of T)( P.Value.CompareTo(Value)<=0, Value)
  End Operator
  <Obsolete("Not Used",True)>
    Public Shared Operator >(ByVal P As PartA(of T) , Value As T) As PartB(OF T)
    Throw  New NotImplementedException()
  End Operator
    <Obsolete("Not Used",True)>
    Public Shared Operator >=(ByVal P As PartA(of T) , Value As T) As PartB(OF T)
    Throw  New NotImplementedException()
  End Operator
End Class

Public Class PartB(Of T As IComparable(Of T))
  Private _CMP As Boolean
  Private _Value As T
  Public Sub New(CmpState As Boolean, Value As T)
    _CMP =CmpState
    _Value = Value
  End Sub
  Public ReadOnly Property Value As T
    Get
      Return _Value
    End Get
  End Property
  Public ReadOnly Property State As Boolean
    Get
      Return _CMP
    End Get
  End Property

    Public Shared Operator <(ByVal P As PartB(of T) , Value As T) As Boolean
    Return P.State AndAlso ( P.Value.CompareTo(Value)<0)
  End Operator
    Public Shared Operator <=(ByVal P As PartB(of T) , Value As T) As Boolean
    Return P.State AndAlso ( P.Value.CompareTo(Value)<=0)
  End Operator
  <Obsolete("Not Used",True)>
    Public Shared Operator >(ByVal P As PartB(of T) , Value As T) As Boolean
    Throw  New NotImplementedException()
  End Operator
    <Obsolete("Not Used",True)>
    Public Shared Operator >=(ByVal P As PartB(of T) , Value As T) As Boolean
    Throw  New NotImplementedException()
  End Operator
 
End Class

---

I use the extension method .__ (I would use ._ but that's not a valid identifier for a method), that does the initial lifting of the type. Since it less visually intrusive than then the implicit conversion operator.

Code:

---

Public Module Exts
  <Runtime.CompilerServices.Extension>
  Public Function __(Of T As IComparable(Of T))(Value As T) As PartA(Of T)
    Return New PartA(Of T)(Value)
  End Function
End Module

---

Took about 15-20 minute to implement as well.


I await the apologies. :wave:

Quote:

---

Originally Posted by AdamPanic2013

I am a big a fan of Jon Skeet and Evil coding. Eg this is valid coding and produces the expected output of bounds checking.

Code:

---

If lower < Value < Upper Then

---

---

No, that will fail in VB.Net and not even compile with Option Strict Off.
Let's say that your variables had the following values:
lower = 2
value = 3
upper = 5
Your code will then be this:

Code:

---

If lower < (value < upper) Then

---

The (value < upper) part will be evaluated as True so the result is

Code:

---

If lower < True Then

---

That, with Option Strict Off will be evaluated as False while with Option Strict turned On gives a compile exception since a Boolean is not the same thing as an Integer and can't be compared.

Quote:

---

Originally Posted by AdamPanic2013

I await the apologies. :wave:

---

You must be joking if you think that clever hack proves your point.

Quote:

---

Originally Posted by AdamPanic2013

Took about 15-20 minute to implement as well.


I await the apologies. :wave:

---

I apologise for not realising that you were advocating writing lots of pointless code in order to make something appear to work that doesn't in order to let you write code that you shouldn't. If I'd realised that we were just being silly then I'd have worn my special hat. :rolleyes: You keep using those GoTos and we'll keep writing proper code.

It does prove my point. You were assuming the type of a, b and c in the expressions and functionality of the operation <. As well that must be the the same in both uses.

You only have to write it once, and put it in a library which you can reference. (It's on NuGet as well)
And how do you define "proper code"? hmm? Is your way the best way for me?

Wrapping values into a specific type can assist in the coding and prevent bugs. It encapsulate the meaning and context of the value, not just its value.
For example F# has a units of measure system over the type double.

Quote:

---

Originally Posted by AdamPanic2013

You were assuming the type of a, b and c in the expressions and functionality of the operation <. As well that must be the the same in both uses.

---

Yes obviously I assumed that since you gave no indication of otherwise in your original code. What has this to do with Goto's?

Quote:

---

Originally Posted by AdamPanic2013

You were assuming the type of a, b and c in the expressions and functionality of the operation <.

---

Of course I was. What reason did I have not to? If you told me that you could jump 20 feet in the air I'd say that you couldn't. If you then whipped out some special machine that you'd built to let you jump 20 feet in the air I would hardly consider that vindication your original claim. Your original claim made no mention of the fact that it required a reasonable amount of additional code to make it work and that also included the need to call an extension method on one of that values rather than using the value itself. Basically, your original statement is simply not true unless you assume facts not in evidence.

Quote:

---

Originally Posted by AdamPanic2013

Is your way the best way for me?

---

Maybe not, but it's the best for the overwhelming majority of people. Recommending that sort of thing to someone who is obviously inexperienced is doing them a great disservice. I just hope that I never have to debug or extend any code written by you or anyone with your approach. You'd have a far easier time quickly understanding code that I've written than vice versa.

Quote:

---

Originally Posted by Niya

After looking up articles and forums posts over the internet in support of using GoTo to play devil's advocate, I can now comment......Stop using GoTos. I've not seen a single argument that shows their necessity in a modern language.

---

Edsger W. Dijkstra said the same thing that started quite a long winded argument with it's use in the Linux kernal. He lost. (but yes i completely agree with you.)

Quote:

---

Originally Posted by jmcilhinney

Of course I was. What reason did I have not to? If you told me that you could jump 20 feet in the air I'd say that you couldn't. If you then whipped out some special machine that you'd built to let you jump 20 feet in the air I would hardly consider that vindication your original claim. Your original claim made no mention of the fact that it required a reasonable amount of additional code to make it work and that also included the need to call an extension method on one of that values rather than using the value itself.

---

Quote:

---

Basically, your original statement is simply not true unless you assume facts not in evidence.

---

If it if looks from your knowledge that it can't be possible, but it is present that it is seemingly is possible then there could be a hole in your knowledge.

Wouldn't even peak your interest, what if it possible?
You even noticed some curious about it. The .__ .

To me the would have suggest something extra is going in, cos that method / member isn't present on Integer / String.
Both of which are Sealed (NotInheritable) Type, so it has to be an extension method. So I know it at could be overloads of a generic function, let say is so signature could T-> Rout.
What is the specific type for Rout? Let me have think and be analytical about it.
OK from experience I know in most cases the operator < returns a Boolean, but the that doesn't tie-in with what happening in the next operator. Where the types involved would Boolean + Integer -> Boolean.
And that it can't be any of the other types I know of, so what else could it?

What about a custom class, cos I know that you can add operators to work over them.

Let call this class PartA (I can think of a better name latter, doesn't take long to refactor that.) , also cos generic are involved it be a PartA(Of T)
I'll need a way to generate a PartA(Of T) from a T (generic), so that could be the .__ part of the equation.

Code:

---

<Extension>
Public Function __(Of T)( Value As T) As PartA(Of T)
  Return New PartA(Of T)( Value )
End Function

---

Then I'll have think about how I could possible implement it.

Code:

---

.Value As T

---

OK. I've got a PartA(Of T) what will the operator type signature be, what types do in need? PartA(Of T) + T -> ?
Could I return another PartA(Of T)? Nope, cos terms of in the next operator I couldn't overload the operator to return a different type.
So it could be another custom class. Ok what state would need to take with me?
1. The middle Value
2. The result of the first comparison.
I shall call it PartB(Of T)

Code:

---

Operator < (p As PartA(Of T), Value As T) As PartB(Of T)
  New PartB( ResultOfComparision := p.Value.ComparedTo(Value) < 0 ,
                            MiddleValue := Value )
End Operator

---

Etc

Quote:

---

Originally Posted by jmcilhinney

Maybe not, but it's the best for the overwhelming majority of people. Recommending that sort of thing to someone who is obviously inexperienced is doing them a great disservice.

---

Where did I suggest that you should?

Quote:

---

Originally Posted by jmcilhinney

I just hope that I never have to debug or extend any code written by you or anyone with your approach.
You'd have a far easier time quickly understanding code that I've written than vice versa.

---

Maybe / maybe not. From some of the code of yours I've seen, yours is spaghetti code and promoting bad practices. For example Default Instances are you serious suggesting recommending them to learners. It was a crutch that was sadly implement by MS to tempt VB6 across to .net cos some (not enough) could grasp the basic Object Oriented Design. Did you know that default instances are Thread Local? Different threads see different instances of that supposedly default instance. Just generate a new instance of the form. Want to pass information to it use parameters to it, overload the constructor.
Passing in similar looking multiple parameters all the time, may it should be a encapsulated into its own object.

One form shouldn't be reaching in to or accesses another forms layout or controls. Use Events or helper methods to do the task for you.


You'd could be surprised by how easy it is to understand my code because I take the time to think about the encapsulation, interfaces (not GUI), inheritance structure and the project structure is it well organised. With XML comments on the methods. A library I built up and use (Exts.) and the methods it contains are designed to work together. It is subdivide into sub-project, to make updates and addition easier to maintain. Majority of the sub-project library work independently of each other so you only need reference to libraries you need.

Attachment 104231

Those extension methods work for me, although I don't see the need for the XML comments in them... (we've been around this particular block too many times before, so let's just leave that alone).

However can you see that there is a large difference between seeing

Code:

---

If b.IsBetween(a, c) Then

---

(which has some fairly obvious intended semantics consistent with the language) and this:

Code:

---

If a.___ < b < c Then

---

which by all reasonable expectations of the language is a compile error? Redefining operators to return something else does not follow the Principle of Least Surprise - if you don't care for it then I'd suggest you haven't spent much time maintaining code written by others who didn't follow it. Either that, or you really don't care for the people who may come after you to maintain your code (or perhaps aren't writing code that others will maintain? In which case, go for it, I guess?)

@AdamPanic2013, I need to ask you to either start a new thread or just stop this discussion since you've now hijacked the thread. This discussion has nothing to do with the Goto statement that the OP asked about.

Why don't you split it out into separate topic?

Quote:

---

Originally Posted by AdamPanic2013

Why don't you split it out into separate topic?

---

Joaciam could do that however, the topic would still have the same name as the original and I am not sure if the name can be changed or not.

I reckon that every learner has tried first the following for bound checking.
Or someone coming from a maths background.

Code:

---

If a < b < c Then

---

Since that what it looks like in mathematics. 0 < x <= 100.
Then figured out, the common method of

Code:

---

If a < b And b < c Then
' even fewer would use the parenthesis version
If (a < b) And (b < c) Then
' And even fewer would use AndAlso
If (a < b) AndAlso (b < c) Then

---

Also can make multiple bound-check smaller. (Then it more a opinion on style of coding)

Code:

---

If (0.__ < x < box.Width ) AndAlso
  (0.__ < y < box.Height) AndAlso
  (0.__ < z < box.Depth ) Then

---

Should be able to change topic title during split process.

Quote:

---

Originally Posted by AdamPanic2013

Why don't you split it out into separate topic?

---

I could if I've found the discussion interesting enough to be moved into its own thread. However I don't. Just because you can change the behaviour of an operator doesn't mean that it makes sense to do so. I've asked you to stop posting in this thread since we don't take lightly on hijacking someone else's thread for their own discussion. So stop posting now!

Sorry. Post withdrawn as I didn't see the full discussion. Other people have raised the issues I have so I'll leave it to them to get replies.