using classes vs. modules

  • Thread starter Thread starter Andy B.
  • Start date Start date
Michael said:
Anything "inacceptable" is just going to be something minor that only
really exists as an issue to you.
Click to expand...

I can not tell you if something is minor or major. You have your own value
system. If you think you can't do whatever for whichever reason that you
consider major, I can not tell you that the reason is a minor reason. Same
vice versa.

As long as basic (major) things don't change, there's no way to C# for me.
If VB will be left behind very far one day, I'll reconsider thinking about
switching to C#. I promise.

My final sentence to the stoy:
There is nothing, and not anybody (including you), that convinces me
nowadays. So, save your energy for working on your C# projects. ;)


Armin
 
Michael C said:
Shared methods. In some *very* rare cases it could be argued that you
should use a module but for something like accessing the database these
should be in a shared function in a class.
Click to expand...

Why?

(BTW: I'd prefer a class too.)
 
Michael C said:
C# has no global functions like CType so it would be of no use.
Click to expand...

Whereas 'IIf' was a simple function like 'Mid', 'CType' is actually an
operator.
 
Michael C said:
I think it is actually easier to use. VB has all these features that are
designed for beginers but they just slow you down when you get a bit of
experience. For example, VB has less compiler checks. Surely if the
compiler picks more errors up for you that is better.
Click to expand...

Could you back this up by examples?
I really don't think there's much arguement in that. VB is missing some
key features. The more I learn about it the more I realise it's missing.
Click to expand...

Which key features?
That's true but I think it gains you enough. I used to use VB but thought
I'd have a look at C# with an open mind. I've never looked back and really
dislike working in VB now.
Click to expand...

Well, that's your personal (subjective) opinion and you are free to have it.
However, just accept that other people may have another opinion which is
also based on their experience.
 
Michael C said:
Yet again I say, C# and VB.net are not so different to compare them to 2
different spoken languages. It would take years to switch from English to
German. To switch from VB.net to C# would take 1 single day at most. When
it is so simple to switch and C# is easier to use and more powerful why
continue with VB?
Click to expand...

It's not that simple. Although there are many syntactical similarities,
often semantics of language elements differ.
These are all fairly minor and illogical reasons. You dislike brackets in
if statements but you don't object to typing the useless Then statement.
That just doesn't make sense.
Click to expand...

'Then' is optional in VB.NET for 'If' blocks. I have never typed it in
VB.NET because I always use the 'If' blocks instead of single-line 'If'
statements.
 
Michael C said:
This is flawed logic. While I am a good developer I am not perfect. I've
received this warning many times and it's helped eliminate what could have
been a bug later. By your logic we should remove all such warnings and run
with option unstrict because real programmers don't need the compiler to
tell them what they're doing wrong.
Click to expand...

Well, VB developers know which values are returned implicitly. I don't
consider implicit return values a source for errors because they are
specified behavior. Even explicit 'return <value>' statements may be
semantically wrong. Should the compiler bark at every statement to make the
developer look at it twice?
 
Michael C said:
They should have not had option strict at all and made it always strict.
If there was a dot net language that did that I would be using it ;-)
Click to expand...

I am glad to have 'Option Strict {On, Off}'. I use 'Open Strict Off' for
early prototypes and quick-and-dirty tools.

In corporate environments I'd adjust the project templates to have 'Option
Strict' enabled by default.
 
Michael C said:
That's just not true, a string in C# can be null, an empty string or a
string of length greater than 1.
Click to expand...

I assume you wanted to write "of length greater than 0".
 
Michael C said:
You're barking up the wrong tree. C# warns about real errors that VB will
miss and only become a problem at run time. As an example, have a look at
this code:

Function ABC As Integer
Dim y as Integer
y = 5
End Function

There are 2 errors in this function that VB will miss. The more minor one
is that y is only ever set and never used.
Click to expand...

This could be either determined using code analysis or a compiler warning.
The more serious one is that it doesn't warn that you have forgotten
to return a value.
Click to expand...

The actual problem is that the function is always returning the /same/
value, which could be determined by code analysis or the compiler.
 
Herfried K. Wagner said:
Why?

(BTW: I'd prefer a class too.)
Click to expand...

Are you talking about the first part or the second part of my sentence. The
very rare case I was talking about was replacing IIf, you could argue that
it makes sense to add something more efficient. For the second part I would
say db functions should go in a class because there will likely be many of
them and having lots of global functions is not a good idea.

Michael
 
Herfried K. Wagner said:
Could you back this up by examples?
Click to expand...

An example would be comparing a string object containing nothing to "". VB
will return true I believe. At first this will help beginners but for an
experienced programmer it will just be a hassle.

I would also say just the syntax of vb, eg Dim X as Integer, is helpful for
beginners but once you get more experience all you need is int x;
Which key features?
Click to expand...

Some examples would be anonymous functions, yield return keyword, pointers.
I know you'll say these are something you never use but in the case of the
first 2 I use these all the time. With regards to pointer these are
something I use less often but in the case when you need them they are
really handy. Generally I use pointers for high speed bitmap modifications,
video manipulation and other interop stuff. You could write a dll in C++ or
C# to handle the pointers but it's quite often better if it's just there.

The other key feature I would mention is intellisense. Of course this is not
missing but it is missing the ease of use of C#'s intellisense.
Well, that's your personal (subjective) opinion and you are free to have
it. However, just accept that other people may have another opinion which
is also based on their experience.
Click to expand...

That's true but some things are purely opinion and some are more than that.
For example me not liking the verbosness of vb is probably opinion but C#
having better compiler checking is more than just an opinion.

Michael
 
Herfried K. Wagner said:
Well, VB developers know which values are returned implicitly. I don't
consider implicit return values a source for errors because they are
specified behavior. Even explicit 'return <value>' statements may be
semantically wrong. Should the compiler bark at every statement to make
the developer look at it twice?
Click to expand...

Obviously not but I think forcing developers to explicitly say what they are
returning is a good thing. I agree it can sometimes be a hassle because I
just want to return the default value but it does make for better code. When
maintaining a piece of code did the developer mean to return the default
value or did they just forget?

Michael
 
Michael C said:
An example would be comparing a string object containing nothing to "". VB
will return true I believe. At first this will help beginners but for an
experienced programmer it will just be a hassle.
Click to expand...

It will return 'True' vor a value comparison, but it won't for a reference
comparison.
I would also say just the syntax of vb, eg Dim X as Integer, is helpful
for beginners but once you get more experience all you need is int x;
Click to expand...

Well, the focus of my interest was on the errors which are picked up by C#
which are not picked up by VB. However, IMO 'Dim x As Integer' is more
readable than 'int x;' because it's clearly visible that it's a variable
declaration.
Some examples would be anonymous functions, yield return keyword,
pointers. I know you'll say these are something you never use but in the
case of the first 2 I use these all the time. With regards to pointer
these are something I use less often but in the case when you need them
they are really handy. Generally I use pointers for high speed bitmap
modifications, video manipulation and other interop stuff. You could write
a dll in C++ or C# to handle the pointers but it's quite often better if
it's just there.

The other key feature I would mention is intellisense. Of course this is
not missing but it is missing the ease of use of C#'s intellisense.
Click to expand...

We won't come to a consensus here. As I said in a previous discussion, the
necessity of these features really depends on what one is doing with the
programming language. It also depends on the programming style. On the
other hand I could throw in declarative event handling (which I consider
crucial because I often use events), XML support (when dealing with lots of
XML), VB's handling of nullable types (no null propagation in C#), ...
That's true but some things are purely opinion and some are more than
that. For example me not liking the verbosness of vb is probably opinion
but C# having better compiler checking is more than just an opinion.
Click to expand...

C#'s compiler checks /differ/ from those of the VB compiler, but this
doesn't make them better necessarily.
 
Michael C said:
Obviously not but I think forcing developers to explicitly say what they
are returning is a good thing. I agree it can sometimes be a hassle
because I just want to return the default value but it does make for
better code. When maintaining a piece of code did the developer mean to
return the default value or did they just forget?
Click to expand...

Personally I am always *aware* of the value returned by the method implicit.
In other words: I am able to see the value although it's not visible in the
code. Even explicit code can contain errors: When maintaining a piece of
code did the developer mean to return 3 or did he want to type 2?

In both cases unit tests are IMHO the best way to find those errors.
 
Herfried K. Wagner said:
It will return 'True' vor a value comparison, but it won't for a reference
comparison.
Click to expand...

Ok, nothing does not equal "" but vb returns true.
Well, the focus of my interest was on the errors which are picked up by C#
which are not picked up by VB.
Click to expand...

I wasn't sure what you were asking about as there were 2 sentences you asked
for more details of. With the compile errors an example is that VB does not
warn when you forget to return a value from a function.
However, IMO 'Dim x As Integer' is more readable than 'int x;' because
it's clearly visible that it's a variable declaration.
Click to expand...

Either is just as readable once you get used to it, however there's just
more typing and reading in VB.
We won't come to a consensus here. As I said in a previous discussion,
the necessity of these features really depends on what one is doing with
the programming language. It also depends on the programming style. On
the other hand I could throw in declarative event handling (which I
consider crucial because I often use events),
Click to expand...

But how often do you really create an event for an object? I consider myself
to use them a reasonable amount but it's still not that big a part of my
day. And now with generics most of the extra code is no longer required in
C#.
XML support (when dealing with lots of XML),
Click to expand...

I don't find I need xml all that often.
VB's handling of nullable types (no null propagation in C#), ...
Click to expand...

Can you give an example of this?
C#'s compiler checks /differ/ from those of the VB compiler, but this
doesn't make them better necessarily.
Click to expand...

Stricter is better imo. In going from vb6 to vb.net things got a lot
stricter and that was a really really good thing. To go a little further is
a better thing really.

Michael
 
Herfried K. Wagner said:
Personally I am always *aware* of the value returned by the method
implicit. In other words: I am able to see the value although it's not
visible in the code. Even explicit code can contain errors: When
maintaining a piece of code did the developer mean to return 3 or did he
want to type 2?
Click to expand...

Well nothing is absolute but by typing the number 3 he is indicating that at
the time he chose to type 3. But by having an implied zero you just don't
know. If the return value is forced then you know at least he had to make a
choice of zero.
In both cases unit tests are IMHO the best way to find those errors.
Click to expand...

But that's the whole point, the error gets fixed at compile time and doesn't
get through to the testing stage. Fixing it using unit testing is not a good
thing, that is a failure of the compiler if it's something simple it could
have picked up. The whole reason dot net is stricter than vb6 is to move as
many errors as possible into the compile time.

Here's an example. I had an app in VB6 which had the line dim f as field.
The problem was both ado and activereports defined a field object. Somehow
the order of the references in the reference dialog got switch so f when
from being an ADODB.Field to an ActiveReports.Field. This didn't get picked
up until it got to the users. Now the vb6 compiler could have easily worked
out that there was something wrong and the line which assigned a value to f
would always product an error. Now dot net has this check for a very good
reason.

Michael
 
Michael C said:
But that's the whole point, the error gets fixed at compile time and
doesn't get through to the testing stage.
Click to expand...

Implicitly returning a value is not an error.

The real error is returning the /wrong/ value in a certain case, which can
be best determined using tests. The compiler is of limited use to test the
semantic contract.
 
Back
Top