Why does vb.net keeps supporting legacy OO undermining syntax

[Sandern]

For some reason the support for old legacy code is still supported in the new VB.Net 2005 version. It is one thing to support it form Vb6 to VB.Net 2003, and not to mark every piece of 'smelly' code as obsolete, or give warning, but still supporting it in VS.Net 2005 + versions is not something i would vote for.

Some co-workers are even being trained at software companies by people that encourage them to use optional parameters etc......why o why


Another thing....why does vb.net chooses different keywords....overrides, shadows, overloads, mustinherit, readonly/writeonly properties on an on i just don't know who's thinking that this helps, but is just DOESN'T....


Here are some small pieces of code that could be just refactored into more neat code....


* On error resume next ==> use decent exception handling!

On error goto ErrorHandler

.... buggy code


Try ..
Catch (....)
Finally
... cool disposal
End Try


* Optional parameters ==> over method overloads


Public Sub DoStateChange(Optional ByVal enforceAll As Boolean = True)
If (enforceAll) Then
'
End If
End Sub

Public Sub DoStateChange()
DoStateChange(True)
End Sub
Public Sub DoStateChange(ByVal enforceAll As Boolean)
If (enforceAll) Then
'
End If
End Sub



Hopefully there are some people that are considering this in the feature....


Thanks.

 

[vis781]

er.. so what is your point? VB.net in relativley still in it's infancy if you compare it to vb. Why wouldn't they still support legacy code? Microsoft is a business it has end users i doubt they are going to all of a sudden stitch up any one who is still making the transition to vb.net, frankly i think it's a good thing, you dont have to use legacy code but it's there if you want. Cant see what the problem is personally.

 

[Sandern]

Re: ...

Cant see what the problem is personally.


===>

There are no guidelines to dis/encourage the use of certain features. Ok, i understand the need of it for conversion purposes etc, but i see now that some companies uses the 'features' as the pro-method of doing things in vb.net 2003 +

Therefore i made my statement. There is no officially posted guideline for using the 'features' hence, some people think that introducing code like optionals etc, is a good think. To my humble opinion you shouldn't use language features that are there only to support old code.

So optionals, and other things that emerged from vb6 could exist in the code because this is legacy, ok maybe...but it should not be used as language features for new code.

 

[vis781]

You'll get no argument from me there, i agree that programmers should aim torward the .net 'way of doing things' (although i do find the IIF function quite usefull from time to time, shame there's no ? conditional like c#) but anyway i digress. Optional parameters, well come on lets be honest they are quite handy, i mean as opposed to writing two + overloaded methods, i know i've done it myself when i've been typing for so long that i think my fingers are gonna quit and bugger off on holiday! My opinion, legacy code support is welcome so long as we don't start to see the devolution of .net and it becomes VB8 or whatever.

 

[ImDaFrEaK]

I agree with VIS and I also support optional parameters and think they should stay... even more I believe optional parameters should become standard among .net in all languages. As far as some of the other implementations, why remove somthing that works just fine? I mean, we know .net can do it, and somtimes we need to code further to get it done, but there is no reason to remove great features of VB just b/c it's old. You have the option not to use it if you wish. Here and there I will or may consider your argument to be legit but I have read several times from on a few different forums suggesting Optional Parameters be removed and i disagree.

 

[ImDaFrEaK]

MS take on it.

Optional Parameters

Visual Basic .NET is unique in its support for both optional parameters and method overloading. Both features are handled by the Visual Basic .NET compiler. For method overloads, the compiler matches the supplied argument list to the appropriate overloaded version of the method and generates a call to that method version in the IL. For example, consider the following call to MessageBox.Show:
System.Windows.Forms.MessageBox.Show("Overload")The IL generated by the compiler for this method call is:
ldstr "Overload"call valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(string)The compiler matches the Visual Basic .NET source code to a specific overloaded version of MessageBox.Show and calls that version in the IL.
Unlike overloaded methods, a method with optional parameters is a single version with default values for one or more parameters. If a parameter value is not supplied, the default value is inserted by the compiler. The default value is inserted in the method call in the calling assembly. If the default values are changed, the calling assembly will continue to use the original default values. Unlike Visual Basic 6, you cannot determine whether parameter values were included in the original method call or if the default values were provided by the compiler. Consider the following call to InputBox:
InputBox("Prompt")The IL generated for this method call is as follows:
ldstr "Prompt"ldstr ""ldstr ""ldc.i4.m1ldc.i4.m1call string [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::InputBox(string, string, string, int32, int32)The default values for the last four parameters were inserted by the compiler and are used for the method call when the IL executes. The InputBox method cannot differentiate between the above call and the following:
InputBox("Prompt", "")Visual Basic no longer includes the IsMissing function to determine if an optional parameter was omitted in the calling code nor is there any special runtime handling of optional parameters. All optional parameters must have a default value for the compiler to insert in the IL when a parameter is omitted.
Since overloaded methods and methods with optional parameters are treated like any other method call at run time, there is no performance-related reason to choose one over the other. However, bear in mind that other languages, most notably C#, do not support optional parameters. Overloaded methods are generally more appropriate than optional parameters if a component is to be used from C# code.
Support for optional parameters gives Visual Basic .NET programmers a distinct productivity advantage over programmers using other languages when dealing with certain components (e.g., COM methods that include optional parameters). For example, compare the following Visual Basic .NET and C# versions of the same call to the SaveAs method of a Word document object:
' Visual Basic .NETDim wrd As New Microsoft.Office.Interop.Word.DocumentClassDim fileName As String = "c:\automation.doc"wrd.SaveAs(fileName)// C#Microsoft.Office.Interop.Word.DocumentClass wrd;wrd = new Microsoft.Office.Interop.Word.DocumentClass();object fileName = "c:\automation.doc";object optional = System.Reflection.Missing.Value;wrd.SaveAs(ref fileName, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional, ref optional);The Visual Basic .NET compiler inserts the default value, System.Reflection.Missing.Value, automatically whereas the C# compiler does not. The C# programmer has no choice but to include every optional parameter in the method call.
Recommendation: Visual Basic will provide significant advantages over other languages when calling methods that accept optional arguments. Be aware that if you author methods that accept optional arguments, and those methods are called from other languages, those languages will have to supply a parameter for each argument position.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchMicrosoftVisualBasicNETInternals.asp