Is microsoft awaring VB.Net too hard to maintain?

[Cor Ligthert [MVP]]

Well, it's pretty obvious that you didn't undestand the goals of the
petition.

What at least me does not agree with you, reading the message I did
completely agree with it, while thinking that Herfried would do that as
well.

Cor

 

[Peter Proost]

Not wanting to start a beer thread but you shouldn't drink dark belgian
beers, as always it are the blondes who are the best ;-) lol

Peter

 

[Kevin]

I meant the property name is "ReadOnly" - not a read only property.

 

[Jim Wooley]

To use a keyword as a property in VB, enclose it in brackets as follows:

Public Property [ReadOnly]() As String

Actually, you can do the following (although I would not recommend it for
maintainablity):
Public Readonly Property [ReadOnly()] as String

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Interface implementation based on identifier equality feels more
object-oriented than declarative interface implementation?

What do you mean? Do you mean the difference between implicit and
explicit implementations?

public void Dispose() {}

vs.

public void IDisposable.Dispose() {}

C# supports both, doesn't VB?

Well, as a result VB.NET is more flexible than C# .

How would that make it more flexible?

 

[Jim Wooley]

I suppose the issue with interface implementation is that you can do the
following in VB but not in C#:

public sub SoYouWantToDisposeMe() implements IDisposable.Dispose

In order to allow the above in VB, it is not good enough to say:
public sub Dispose()

You have to explicitly state which method implements which portion of the
interface.
Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

 

[Herfried K. Wagner [MVP]]

I suppose the issue with interface implementation is that you can do the
following in VB but not in C#:

public sub SoYouWantToDisposeMe() implements IDisposable.Dispose

That's exactly what I mean. In C# one has to guess that a member implements
a certain method of an interface whereas it's not necessary to lookup the
interface's member in VB.NET in order to understand the source code.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

That's exactly what I mean. In C# one has to guess that a member
implements a certain method of an interface whereas it's not necessary
to lookup the interface's member in VB.NET in order to understand the
source code.

That is easily remedied by placing them in a region:

#region IDisposable members

public override void Dispose() {
....
}

#endregion

Clear as day.
If you let Visual Studio (2005) create the stubs for the implementation,
it places them in a region like this.

 

[Kevin]

Thanks Jim. That's what I was looking for.

To use a keyword as a property in VB, enclose it in brackets as follows:

Public Property [ReadOnly]() As String

Actually, you can do the following (although I would not recommend it for
maintainablity):
Public Readonly Property [ReadOnly()] as String

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

I meant the property name is "ReadOnly" - not a read only property.

 

[Michael D. Ober]

In this particular case, VB has it right. The "implements" clause on the
event procedure makes the language more readable. On the other hand,
iterators are far more difficult in VB than in C#. VB doesn't have the
"yield" statement.

Mike Ober.

 

[Theo Verweij]

There are also things you cannot do in C# that yo can do in VB.
These are language specific features, and these are chosen and developed
by the language teams. Example of these things are the My keyword in VB,
optional parameters in VB and shared classes in vb (called modules).
These things are not available in C#.

 

[Theo Verweij]

Can anyone give an example where you can point out that VB2005 isn't
object oriented?

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Still, those are just tools, they don't limit what you can do with the
languages, only how you can do it.