[Mono-list] RE: Platforms Mono will support?

[Chris Daly]

>> Ximian has done an increadable job with their C# compiler. I'm sure they
>> could do as good a job on a VB.NET one.
> The question is why ;) and when. I think (...) their focus (and all other
> mono developers) is to finish the current projects.
>
> See Topic "VB.NET" where Miguel de Icaza wrote
> "I believe that a VB.NET compiler will require a different semantic
analysis
> back-end, even requiring a complete re-implementation of it."
>
> BTW: Have you compared the .NET VB language with VB <=6?
> I don't have much experience with VB, but as far as i know, many things
have
> changed for .NET , but the differences to C# aren't that big, are they?
>
> Carsten

I usually lurk on this list and I haven't studied the Mono C# implementation
very closely, however having worked on language tools for both C# and VB.Net
I want to say that at first glance the two languages look almost identical,
but the more you look the more differences you will find. Here is a partial
list of the differences I've run into:

- operator overloading (C# has it, VB.Net does not)

- I would need to double check this, but I believe VB does not allow you to
define "add" and "remove" for events like C# does.

- VB allows you to nest types inside of interfaces (I think they have to be
non-public), but C# does not.

- VB Modules.  VB has a construct called the Module which is like a class
with no constructor which has only static methods (It can also have nested
types).  The interesting thing about modules is how they expose the stuff
inside.  For example take the C# code:

public class Foo {
  public static void DoSomething () { }
  public class Bar { }
}

If that were a VB module I could call the method from outside without
prefixing the class name (In C# you would have to say Foo.DoSomething()).  I
could also reference Bar directly from outside without referencing Foo.Bar.
In other words modules take all of the names they expose and push them up
one level when it comes to resolving names, which leads to the next
thing....

- Name resolution rules.  The name resolution rules are different for C# and
VB primarily because of the influence of modules, but there are some other
little quirks.  In VB you cannot have the using construct (called "imports"
in VB) nested inside a namespace, so the C# code:

namespace N1 {
  using System;
}

has no VB equivalent.  So VB "imports" are all at the file level.  But
here's something you can do in VB but not in C#:

Imports System.Collections.ArrayList

In other words, your using/imports names a type instead of a namespace
(using aliases are pretty much the same for VB and C#).

- Parameterized properties.  Here's another thing you can do in VB but not
C#.  Properties can take parameters, so you can have code like this:

x = myFoo.Item["x"]
myFoo.Item["x"] = y

Where Item is a property defined on the Foo class.  The closest thing to
this in C# is indexers.  What C# calls an indexer is called the "default
property" in VB.

- Method implements.  VB has a way of making one method body implement a
number of different interface contracts.  So you can say something like
this:

Public Function X() Implements IFoo.FooX, IBar.BarX, IBaz.BazX
' body code here
End Function

Note that the names X, FooX, BarX, BazX are arbitrary but the method
signatures of course have to match for this to be legal.  There is a similar
way to make one method body be the event handler for a number of different
events.

- Quality of specs.  This is a really big one.  I don't think there are many
places where the Microsoft C# compiler (i.e. the reference compiler) is out
of whack with the specs, but for VB there are a lot (I posted one on another
list, dotnet-language-devs I think, about how the compiler allows keywords
to be used as identifiers in places where the spec's grammar disallows it).
So you are going to have to decide whether to do it like MS says or like MS
does.  Hopefully this will get a lot better if/when Microsoft submits the VB
language to the ECMA standards body like they did for C#.

I'm sure I'm forgetting some differences - wait here's another: In VB an
enum must have at least one enumeration literal, but not so in C#.  There
are a lot of quirky little things.  I've focused mostly on the high-level
constructs because that's what I'm most familiar with, but I think when you
get down into method bodies and look at statements and expressions you will
find a lot of differences there too.  VB is more lax about declarations and
return statements are not necessary (the function will just return null or 0
or false if you forget a return statement).

I hope this helps somewhat.  I think Mono is a great project!  It's open
source so everyone can contribute what they want, but I personally think you
guys can make better progress right now focusing on the multi-platform
support because that's where you can really break new ground.  It would be
pretty stunning if you can get a MacOS X implementation out there before MS!
:-)


Chris