Ich probiere seit einiger Zeit die neue VisualStudio Version Orcas bzw. VS2008 in der Beta1 aus. Was mich natürlich besonders daran interessiert, sind die neuen VB Features. Nach langem Suchen musste ich feststellen, dass bestimmte Funktionen noch nicht in Orcas Beta 1 zu finden sind. Das betrifft z.B. Lambda Funktionen - also inline Funktionen. Während ich in C# eine lambda-funktion so schreiben kann x => x+1 (Eine Funktion mit dem Parameter x der x + 1 zurückgibt) sollte man in VB dies schreiben können Function(x) x+1. Anscheinend kann dies der Beta Compiler noch nicht. Was blieb mir anderes übrig als mit LINQ in C# weiter zu experimentieren. (Ich muss sagen, langsam gefällt mir C#.)
Werden solche kleinen Probleme in der endgültigen Version von VB 2008 behoben sein?
Ja, die gröbsten Sachen werden wohl in VB laufen, aber man wird keine großen Sprünge machen können. Es sieht so aus als würde C# 3.0 einen Produktivitätsgewinn gegenüber VB 9.0 haben. Was besonders ironisch ist C# wird dynamischer sein als VB. (Das wird aber mit VBx sicherlich wieder aufgeholt werden) Warum?
Keine Collection Initializer in VB!Während C# so ziemlich jeden Typ ableiten kann, kann dies VB anscheinend nicht.
Im
C# kann ich einenen anonymen Typen definieren:
var obj = new { Property1 = "Hallo", Property2 = 12345};VBDim obj = New With { Property1 = "Hallo", Property2 = 12345}Was ist wenn ich ein Array erstellen will?
C#var list = new[] {1,2,3};VBDim list = New Integer() {1,2,3}Ärgerlich ist hier, dass ich bei VB den Datentyp des Arrays angeben muss. Warum kann dieser nicht abgeleitet werden wie bei C#?Mit C# kann man auch Auflistungen erstellen, die vom Compiler abgeleitet werden können.
var list = new[] { new {Property1 = "hallo"}; new {Property1 = "test"};};Sowohl der Anonyme Typ als auch die Anonyme Collection können abgeleitet werden. Man kann also einen ObjektInitializier (also {Property=Value}) auch verschachteln und damit Collections bauen.
http://oakleafblog.blogspot.com/2007/06/will-visual-basic-90-have-collection.html sagt, dass auf mysteriöse Weise in den neusten HandsOnLabs zu VB 9 alle Verweise auf Collection Initializer verschwunden sind. Noch schlimmer: Keins der angeführten Beispiele soll funktionieren. Wie man also in Zukunft dieses C# Beispiel in VB umsetzten wird, ist also noch unklar.
Was gibt es sonst Neues? http://www.panopticoncentral.net/archive/2007/06/27/21113.aspx- Das InternalsVisibleToAttribute wird endlich vom VB Compiler erkannt. Damit ist es möglich, dass man die mit Friend gekennzeichneten Klassen und Member aus einer anderen Assembly aufrufen kann. Dies ist für UnitTests wichtig! Zwar konnte man bisher schon dieses Attribut in VB verwenden, aber die entsprechenden Friend Klassen wurden nicht angezeigt.
- Relaxed Delegates. Hat man z.B. einen Click EventHandler für einen Button und man möchte dieses Ereignis verarbeiten, musste man immer die entsprechende Signatur des EventHandler Delegates als Verarbeitungsmethode schreiben. In der Regel also Button1_click(sender as Object, e as EventArgs). Das war lästig, da weder sender noch e benutzt wurden (Es sei den EventArgs hatte wirklich wichtige Argumente). Es wird aber nicht das sog. Currying unterstützt, d.h. dass man auch nur einen Parameter verwenden kann, statt alle Parameter wegzulassen.
- VB Programme können auch ohne Microsoft.VisualBasic.dll kompiliert werden. Der VB Compiler hat bisher für bestimmte late-binding Funktionen von VB dieses Dll benötigt.
- Es können Objektmember auf Interfaces aufgerufen werden. Es gibt zwar keine Beispiele hierzu, aber ich stell mir das als Extrem LateBinding vor. Beispiel:
Interface ITest
Sub CallFunktion
End Interface
Class Person Implements ITest
Property Name
End Class
Dim p as ITest = New Person
p.Name
Ich könnte ein Objekt zu einem Interface casten und dann auf diesem Interface ein Member des Objekts aufrufen, obwohl die Variable ja jetzt ein Interface ist. (Wofür soll das gut sein???)
- Es wird einen ? Operator wie in C# geben, um If Else Condition in Kurzform schreiben zu können. (Was für ein Blödsinn!)
Was wird nicht umgesetzt?Erlaubt es C#, dass in Labdas auch Statements wie - Console.WriteLine(x) - möglich sind, werden in VB nur Expressions erlaubt sein - also x+1. Dadurch wird VB um echte Funktionalität für LINQ beschnitten. Auch einen yield Operator wird es in VB nicht geben. Dadurch wird VB Programmierern die Möglichkeit genommen, wirklich produktiv und kreativ mit LINQ zu arbeiten. (Shame on you Microsoft!)
Insgesamt bin ich schon sehr enttäusch von den neuen VB Features! Echt schwache Leistung Microsoft. Ich werde wohl für den Einsatz von LINQ C# einsetzten
MÜSSEN, obwohl ich lieber VB verwenden würde!
