using classes vs. modules

[Michael C]

Nope. It's background compiler. Google.

I did a google but I'm not convinced. It doesn't show anything that would
require a compile, all it shows is simple typing errors, missing brackets,
semi-colon etc.

Michael

 

[Herfried K. Wagner [MVP]]

Can't you only raise an event in the class in which it is defined? So I
don't really so what this custom raiseevent does for you, you can just
call the function yourself.
Encapsulation.

Anyway, this has got to be the most obscure reference you could have
possibly found in comparing C# to VB. Same goes for the <= issue. Surely
if this is what you're bringing up you can see that you're really
stretching here trying to find anything to clutch onto.

I am thinking the same about the features you are mentioning. Value
comparison rules for strings in VB, for example. That's really no problem
in VB. As you can see, it's really a matter of personal preference which
style and feature set somebody prefers.

 

[Michael C]

Encapsulation.

The function is encapsulated in the class.

I am thinking the same about the features you are mentioning. Value
comparison rules for strings in VB, for example. That's really no problem
in VB. As you can see, it's really a matter of personal preference which
style and feature set somebody prefers.

That was just one thing I mentioned. Things like poor intellisense, extra
typing all day, lack of yield return keyword, lack of pointers and the
language being more aimed at beginners are all major problems. When compared
to something obscure about events there is a big difference.

Michael

 

[Herfried K. Wagner [MVP]]

The function is encapsulated in the class.

But a function is something different than an event or a delegate. The
event support in VB enforces a more consistent pattern.

That was just one thing I mentioned. Things like poor intellisense, extra
typing all day, lack of yield return keyword, lack of pointers and the
language being more aimed at beginners are all major problems. When
compared to something obscure about events there is a big difference.

Note that 'RaiseEvent' customization in VB is not the only difference I
mentioned. I consider it one of the smaller differences compared to the
whole event infrastructure VB provides, "logic-aware" support for nullable
types, exception filters (very important), declarative interface
implementation and method mapping, 'My', ...

I can only repeat what I have already said: As you can see, it's really a
matter of personal preference which style and feature set somebody prefers.

 

[Tom Shelton]

But a function is something different than an event or a delegate. The
event support in VB enforces a more consistent pattern.

I simply can't agree on this. They just handle things differently, but in the
end the results are exactly the same... Total non-issue.

Note that 'RaiseEvent' customization in VB is not the only difference I
mentioned. I consider it one of the smaller differences compared to the
whole event infrastructure VB provides,

To each his own. I actually prefere the C# way - though, I've never liked the
use of the += and -= operator for this. It makes a bit of sense considering
the multicast nature of events, but it's never felt quite right. I actually
prefere the AddHandler/RemoveHandler syntax in VB.NET - though it does seem a
bit wordy for a C-style langauge

"logic-aware" support for nullable
types,

Depends on the type of work your doing.

exception filters (very important),

Nice, I guess - but I certainly wouldn't rate it as "very important".

declarative interface
implementation and method mapping,

For the most part - YUCK! Though, the method mapping can be handy on
occasion.

'My', ...

If you say so.

I've not missed a single one of the features you've mentioned in C# - and to
be honest, I've rarely seen most of them actually used in VB.NET code either.

I think things like XML litterals and easy late binding are much more
important to the current version of VB.NET then most of the other stuff you've
mentioned.

I can only repeat what I have already said: As you can see, it's really a
matter of personal preference which style and feature set somebody prefers.

Now that is true. I certainly don't hate VB.NET - I just prefere C#

 

[Herfried K. Wagner [MVP]]

Nice, I guess - but I certainly wouldn't rate it as "very important".

Exception filters are rarely used, but if someone is aware of their
existence, they are a valuable feature. Their use should be encouraged, and
it's unfortunate that C# doesn't provide them (this is not a big problem as
it does not affect interoperability between the two languages). As a VB
developer I am missing them in C#.

I think things like XML litterals and easy late binding are much more
important to the current version of VB.NET then most of the other stuff
you've
mentioned.

Depends on the type of work your doing.

;-)

 

[Michael C]

But a function is something different than an event or a delegate. The
event support in VB enforces a more consistent pattern.

Maybe it is a minor advantage but considering it's limited to your own code
in a single class I can't see the problem with a function.

Note that 'RaiseEvent' customization in VB is not the only difference I
mentioned. I consider it one of the smaller differences compared to the
whole event infrastructure VB provides, "logic-aware" support for nullable
types,

I actually consider this a disadvantage in VB. I've always disliked the way
databases work with null and found it unecessary. It worked ok in joins but
it's use in an if statement is completely unecesary imo. I think VB actually

exception filters (very important),

I certainly wouldn't say very important.

declarative interface implementation and method mapping, 'My', ...

I wouldn't say very important to any of those either.

I can only repeat what I have already said: As you can see, it's really a
matter of personal preference which style and feature set somebody
prefers.

While I agree on some fronts so points are not just a matter of opinion.
Things like better compiler checking and better intellisense are not a
matter of opinion.

Michael

 

[Jason Keats]

The function is encapsulated in the class.


That was just one thing I mentioned. Things like poor intellisense, extra
typing all day, lack of yield return keyword, lack of pointers and the
language being more aimed at beginners are all major problems. When compared
to something obscure about events there is a big difference.

Michael

The facts are that VB is:
- easier to read than C#, especially for us VB programmers (improving
maintainability)
- just as quick to write as C#, if you use the IDEs code completion
features (or even better, the Snippet Editor)
- safer (no pointers or unmanaged code)
- much easier for COM or XML (and just about everything else)
- more popular than C# (counted by downloads of Express versions)
- more fun than C# <g>

However, none of that matters!

Because...

An F# programmer will soon tell you that VB and C# both suck by comparison.

Someone will wonder why you're not using Subversion, ReSharper, NUnit,
NCover, NDepends, NHibernate, CC.NET...

A code generation guru will say you should be using MyGeneration,
CodeSmith, T4, LLBLGen Pro, or... to create most of your program.

An MDA practitioner would say create your PIM using UML, then
automatically transform (or translate) it to C code.

Microsoft will soon be telling you to use Oslo.

 

[Michael C]

The facts are that VB is:

None of these are facts, in fact most are false.

- easier to read than C#, especially for us VB programmers (improving
maintainability)
Hardly.

- just as quick to write as C#, if you use the IDEs code completion
features (or even better, the Snippet Editor)

That's just plain wrong when the intellisense is significantly better in C#.

- safer (no pointers or unmanaged code)

That is just a crazy statement. If you want safety then don't use pointers.
If you want functionality though, pointers can be useful in a wide range of
applications.

- much easier for COM or XML

The kind of com work I do (directX, imapi etc) vb can't do. As for office
automation, vb does have an edge apparently but I'd rather have a whole
world of functionality available than be able to program word automation.

(and just about everything else)
No.

- more popular than C# (counted by downloads of Express versions)

This is not correct. C# is simply more popular than VB.net. That site
includes vb6 and vba which is misleading. I have found that vb.netters have
no trouble grabbing that unquestioned and running with it.

- more fun than C# <g>

I'm not sure struggling with poor intellisense all day long is fun. I found
VB to be quite infuriating. How many times a day do you need to push escape
to get rid of the intellisense that keeps poping up.

Michael

 

[Rory Becker]

Hello Jason,

However, none of that matters!

Because...

An F# programmer will soon tell you that VB and C# both suck by
comparison.

Someone will wonder why you're not using Subversion, ReSharper, NUnit,
NCover, NDepends, NHibernate, CC.NET...

A code generation guru will say you should be using MyGeneration,
CodeSmith, T4, LLBLGen Pro, or... to create most of your program.

An MDA practitioner would say create your PIM using UML, then
automatically transform (or translate) it to C code.

Microsoft will soon be telling you to use Oslo.

You forgot to mention productivity tools: RefactorPro and Coderush (although
you did mention resharper) ;P

 

[Jason Keats]

None of these are facts, in fact most are false.


That's just plain wrong when the intellisense is significantly better in C#.


That is just a crazy statement. If you want safety then don't use pointers.
If you want functionality though, pointers can be useful in a wide range of
applications.


The kind of com work I do (directX, imapi etc) vb can't do. As for office
automation, vb does have an edge apparently but I'd rather have a whole
world of functionality available than be able to program word automation.


This is not correct. C# is simply more popular than VB.net. That site
includes vb6 and vba which is misleading. I have found that vb.netters have
no trouble grabbing that unquestioned and running with it.


I'm not sure struggling with poor intellisense all day long is fun. I found
VB to be quite infuriating. How many times a day do you need to push escape
to get rid of the intellisense that keeps poping up.

Michael

You seem to have missed the point of my post.

Coding is a minor part of software development. The IDE is also just one
of many tools you should be using.

Many people generate large parts of their program - so the language and
IDE is irrelevant. It's the model or generator/templates that you should
be refining.

All .NET languages compile to MSIL - so use whatever language you prefer.

There are better .NET languages than VB and C# (which most agree are
almost equal) - so why aren't you using them?

 

[Rory Becker]

Hello Jason,

You seem to have missed the point of my post.

Coding is a minor part of software development. The IDE is also just
one of many tools you should be using.

Many people generate large parts of their program - so the language
and IDE is irrelevant. It's the model or generator/templates that you
should be refining.

All .NET languages compile to MSIL - so use whatever language you
prefer.

There are better .NET languages than VB and C# (which most agree are
almost equal) - so why aren't you using them?

An even more important point is that the C# point of view doesn't matter
to a VB programmer..

We have chosen Vb.Net for our own reasons and really do not care to have
you (Michael) jump into our forum only to try to convince us that we are
wrong. There are many hundreds of thousands of VB programmers of *all* levels
throughout the world who are very happy with their choice of language. It
serves us very well.

There are additional things which would allow it to be even better for one
task or another, but in general, it is fine.
The same can be said of C# I'm sure.

We have listened to all your arguments and largely rejected them as subjective.


We are happy here, otherwise we would have already moved.

Please take this thread offline as it has long since left the indicated subject
matter.

Thankyou

 

[Michael C]

You seem to have missed the point of my post.

Well I don't know, I did respond to each of your points. Did you make them
so I would not respond.

Coding is a minor part of software development. The IDE is also just one
of many tools you should be using.

Maybe you code differently to me but I write code most of the day in either
C# or sql. Every programmer I have ever met or worked with has been pretty
much the same (excluding ms access programmers).

Many people generate large parts of their program - so the language and
IDE is irrelevant.

As far as time goes they don't spend most of the time in designers though.

It's the model or generator/templates that you should be refining.

All .NET languages compile to MSIL - so use whatever language you prefer.

I don't write in IL so what language I use is important to me. By your
arguement everything ends up being machine code so it doesn't matter if we
use C or assembler.

There are better .NET languages than VB and C# (which most agree are
almost equal) - so why aren't you using them?

Such as?

 

[Michael C]

An even more important point is that the C# point of view doesn't matter
to a VB programmer..
We have chosen Vb.Net for our own reasons and really do not care to have
you (Michael) jump into our forum only to try to convince us that we are
wrong. There are many hundreds of thousands of VB programmers of *all*
levels throughout the world who are very happy with their choice of
language. It serves us very well.

There are additional things which would allow it to be even better for one
task or another, but in general, it is fine.
The same can be said of C# I'm sure.

We have listened to all your arguments and largely rejected them as
subjective.

We are happy here, otherwise we would have already moved.

Please take this thread offline as it has long since left the indicated
subject matter.

Why then are you reading it? Why do you beg me to stop writing yet you can't
being yourself to stop reading? Doesn't make sense.

Michael

 

[Harald M. Genauck]

Hi Jason, Rory,

You forgot to mention productivity tools: RefactorPro and Coderush
(although you did mention resharper) ;P

Nice tool lists

Just one thought:

You may have und use them, if you need them.
But there is no need to use them, if you have them.

;-)


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[Harald M. Genauck]

- more popular than C# (counted by downloads of Express versions)

This is not correct. C# is simply more popular than VB.net. That site
includes vb6 and vba which is misleading. I have found that
vb.netters have
no trouble grabbing that unquestioned and running with it.

Which site do you mean?

I cannot believe that they include VB6 and VBA, because VB6 never had a
free downloadable Express version, and VBA never has been a separate
available product.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[J.B. Moreno]

I simply can't agree on this. They just handle things differently, but in the
end the results are exactly the same... Total non-issue.

And I simply can't agree with this. Conceptually it's entirely
different from other methods (procedures or functions), just like
properties are.

And this is where VB has it all over C# as it makes the difference
clear. In C# events appear to be little different than other
delegates.

But they aren't just another delegate. Conceptually an event is user
code called by external code (typically the system) in *response* to
something happening. While an event may do something, it's not
/called/ to do something, it does it in response to something else.

By using the declarative syntax, VB makes it clear that an event isn't
just another procedure that can be called to do something, that it's
*just* an event handler.

 

[Tom Shelton]

And I simply can't agree with this. Conceptually it's entirely
different from other methods (procedures or functions), just like
properties are.

And this is where VB has it all over C# as it makes the difference
clear. In C# events appear to be little different than other
delegates.

But they aren't just another delegate. Conceptually an event is user
code called by external code (typically the system) in *response* to
something happening. While an event may do something, it's not
/called/ to do something, it does it in response to something else.

By using the declarative syntax, VB makes it clear that an event isn't
just another procedure that can be called to do something, that it's
*just* an event handler.

No offense, but I find the above a very weak defense. Fact - an Event in C#
and VB.NET IS just a delegate. End of story. And in fact, and event handler
is just another procedure that can be called to do something - the delegate is
just a typesafe pointer to that procedure. All the declarative syntax does is
ugly up the code - IMHO. Especially when you want to attach the procedure to
multiple sources. This is of course a personal preference, and is very
subjective - just as I'm sure you find some of the C# or C-style syntax
objectionable.

My objection to Herfried was more about the fact that I can and do have just
as much control over my events and how they are raised in C# as you do in
VB.NET. The fact that you choose VB.NET and I choose C# does not limit you or
I in any way in handling or raising of events.

 

[Herfried K. Wagner [MVP]]

No offense, but I find the above a very weak defense. Fact - an Event in
C#
and VB.NET IS just a delegate.

In fact even the CLI is aware of events as a distinct element.

The VB compiler emits the '.fire' directive for the custom 'RaiseEvent'
implementation, which is also defined at CLI level (ECMA-335, Common
Language Infrastructure (CLI), Partition II, Section 18 ("Defining events"),
available online at
(<URL:http://www.ecma-international.org/publications/standards/Ecma-335.htm>).

VB's event model is stronger than C#'s in terms of semantics.

 

[Tom Shelton]

In fact even the CLI is aware of events as a distinct element.

I am aware of that... But, that doesn't change the fact that they are
implemented as delegates.

The VB compiler emits the '.fire' directive for the custom 'RaiseEvent'
implementation, which is also defined at CLI level (ECMA-335, Common
Language Infrastructure (CLI), Partition II, Section 18 ("Defining events"),
available online at
(<URL:http://www.ecma-international.org/publications/standards/Ecma-335.htm>).

VB's event model is stronger than C#'s in terms of semantics.

If you say, so. I just don't see that big a difference - other then VB.NET
has a formalized concept of raising an event, C# treats it as a method call
(sort of). Different symantics, same result.