using classes vs. modules

[Cor Ligthert[MVP]]

Herfried,

The record in the longest thread in this newsgroup is in my idea in hands
from Fergus and Nick.

Are you helping Michael to break that record?



Cor

 

[Herfried K. Wagner [MVP]]

Ok, nothing does not equal "" but vb returns true.

Well, just use 'Is' if you want a reference comparison only.

Guess why 'String.IsNullOrEmpty' has been introduced: Basically to achieve
the same behavior in programming languages which do not provide intrinsic
support for it.

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.

I think that the compilers cannot be compared in this regard because C# does
not support implicit initialization of local variables and implicit return
values whereas VB supports both.

Either is just as readable once you get used to it, however there's just
more typing and reading in VB.

I really wonder if you read/scan your code sequentially,
character-by-character. Personally I am not doing that. When taking a
quick look at source code I do not even "read" 'Dim' -- it's just the shape
of the keyword that indicates that the line contains a variable declaration.
By taking this approach I am faster in VB than in C-style languages, which I
have used a lot.

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.

I often handle events. Declarative syntax simplifies that because the code
used to wire up the event handler isn't spread over multiple methods in the
code.

And now with generics most of the extra code is no longer required in C#.

I am not able to see the relation to events...

I don't find I need xml all that often.

I don't need it that often too, but there are for sure some cases in which
XML is used extensively, mostly in Web applications and applications
spitting out Office Open XML or similar XML formats.

Can you give an example of this?

When comparing nullable variables, the result of the comparison is null in
VB if either of the operands is null, which is not the case for C#, where
the result is still a Boolean value.

Stricter is better imo.

As you say: IMO. I have to disagree.

 

[Michael C]

Well, just use 'Is' if you want a reference comparison only.

Of course but my point was the in VB nothing somehow equals a certain
instance of an object (string.Empty). This is something obviously designed
to help beginners but something that more advanced users would probably
prefer not to have. It's fairly easy to understand but under what other
circumstances do we get similar inconsistancies?

Guess why 'String.IsNullOrEmpty' has been introduced: Basically to
achieve the same behavior in programming languages which do not provide
intrinsic support for it.

A much better solution.

I think that the compilers cannot be compared in this regard because C#
does not support implicit initialization of local variables and implicit
return values whereas VB supports both.

I don't see why we can't make a comparison. VB could have the same check.

I often handle events. Declarative syntax simplifies that because the
code used to wire up the event handler isn't spread over multiple methods
in the code.

Handling events is not where C# has a disadvantage. Attaching to the event
in a different routine is no problem at all, in fact it is the preferred
method. The event is attached somewhere else besides the callback so it
makes more sense to have it declared elsewhere. Where C# has the
disadvantage is when creating an object and creating your own events for
that object. There is a significant amount of extra typing when creating
your own events.

I am not able to see the relation to events...

I don't need it that often too, but there are for sure some cases in which
XML is used extensively, mostly in Web applications and applications
spitting out Office Open XML or similar XML formats.

I haven't really seen the xml in vb so can't really comment in this regard.

When comparing nullable variables, the result of the comparison is null in
VB if either of the operands is null, which is not the case for C#, where
the result is still a Boolean value.

Surely it's better to have a boolean result? Why have the inefficiency of
returning an object?

As you say: IMO. I have to disagree.

Fair enough although the entire industry has moved towards greater
strictness and I think it's fairly universally excepted that the greater
strictness of .net is far superior to vb6. Also pretty much every vb
developer says that option strict should always be used (including you I
presume). So if option strict is so good why is a lack of strictness on this
one issue a good thing?

Michael

 

[Herfried K. Wagner [MVP]]

Of course but my point was the in VB nothing somehow equals a certain
instance of an object (string.Empty). This is something obviously designed
to help beginners but something that more advanced users would probably
prefer not to have. It's fairly easy to understand but under what other
circumstances do we get similar inconsistancies?

I don't think this is designed to help beginners. It's just a design choice
which I consider useful keeping in mind that VB provides distinct operators
for value and reference comparison for reference types.

A much better solution.

IYO, but not IMO.

I don't see why we can't make a comparison. VB could have the same check.

It could have the same check, that's true. But in contrast to C# the VB
code will compile and the function will return a defined value.

Handling events is not where C# has a disadvantage. Attaching to the event
in a different routine is no problem at all, in fact it is the preferred
method.

Well, it's the only available method in C#, but it's not the preferred
method in VB which attempts to support a declarative programming style over
an imperative one.

You can now using EventHandler<int> now instead of creating an event
handler class.

ACK. I wasn't thinking of creating my own event. Nevertheless, even in
this case VB provides more control by supporting custom implementations of
'RaiseEvent' ;-).

Surely it's better to have a boolean result? Why have the inefficiency of
returning an object?

Well, that's how I'd expect it to behave based on common sense logic: The
result of a comparison to something unknown to a certain value should be
"unknown" and neither "true" nor "false".

Fair enough although the entire industry has moved towards greater
strictness and I think it's fairly universally excepted that the greater
strictness of .net is far superior to vb6. Also pretty much every vb
developer says that option strict should always be used (including you I
presume). So if option strict is so good why is a lack of strictness on
this one issue a good thing?

I do not see a trend in the entire industry moving towards greater
strictness. Especially in the field of Web development lots of companies
are making use of very tolerant programming languages because of their ease
of use. One might argue that they produce "disposable code", and I would
not disagree. Nevertheless, that's a large part of the software development
business.

 

[Michael C]

I don't think this is designed to help beginners. It's just a design
choice which I consider useful keeping in mind that VB provides distinct
operators for value and reference comparison for reference types.

Well it is something that would confuse beginners (if nothing did not equal
"") and it does make it easier for someone to start programming. On the
other hand the expert says WTF, why does this particular data type behave
differently to every other data type in the language.

IYO, but not IMO.

Consistency is something I value, I guess you don't.

It could have the same check, that's true. But in contrast to C# the VB
code will compile and the function will return a defined value.

Of course it will function but it might also malfunction.

Well, it's the only available method in C#, but it's not the preferred
method in VB which attempts to support a declarative programming style
over an imperative one.

I prefer to have the 1 method myself.

ACK. I wasn't thinking of creating my own event. Nevertheless, even in
this case VB provides more control by supporting custom implementations of
'RaiseEvent' ;-).

Can you give an example. I doubt there is anything with events VB can do
that C# can't.

Well, that's how I'd expect it to behave based on common sense logic: The
result of a comparison to something unknown to a certain value should be
"unknown" and neither "true" nor "false".

Really? I've always foung it kind of bizzare that databases behave in this
way. It's seems completely unnecessary to me and adds absolutely nothing.
All I care is whether the objects are equal or not. In the odd occassion
when I need to consider null seperately then I can create a seperate check.
I'm not really sure how you'd take advantage of the vb implementation
anyway, something like this??

object res = (Date1 = Date2)
if res is nothing then do something

why not just check for null explicitly?

I do not see a trend in the entire industry moving towards greater
strictness. Especially in the field of Web development lots of companies
are making use of very tolerant programming languages because of their
ease of use. One might argue that they produce "disposable code", and I
would not disagree. Nevertheless, that's a large part of the software
development business.

Really? Web has had a *huge* increase in strictness from asp to asp.net. Asp
had absolutely no strictness at all at compile, ever error was detected at
runtime.

Michael

 

[Michael C]

Implicitly returning a value is not an error.

Not always but quite often.

The real error is returning the /wrong/ value in a certain case,

No, that's a different error.

which can be best determined using tests. The compiler is of limited use
to test the semantic contract.

Of course but the more it can do the better.

Michael

 

[Herfried K. Wagner [MVP]]

Well it is something that would confuse beginners (if nothing did not
equal "") and it does make it easier for someone to start programming. On
the other hand the expert says WTF, why does this particular data type
behave differently to every other data type in the language.

Well, I do not see a problem here. I have never seen a problem arising from
how VB works regarding string value comparisons, and I have seen a lot of VB
code.

Can you give an example. I doubt there is anything with events VB can do
that C# can't.

Just take a look at the third event syntax definition:

Event Statement
<URL:http://msdn.microsoft.com/en-us/library/6hwhs172.aspx>

VB supports customization of 'RaiseEvent', which is not supported by C#.

Really? I've always foung it kind of bizzare that databases behave in this
way. It's seems completely unnecessary to me and adds absolutely nothing.
All I care is whether the objects are equal or not. In the odd occassion
when I need to consider null seperately then I can create a seperate
check. I'm not really sure how you'd take advantage of the vb
implementation anyway, something like this??

Well, I consider the C# semantics rather useless because they "break basic
laws of logic and mathematics", as Bill McCarthy says:

C# defies logic - @ Head

Really? Web has had a *huge* increase in strictness from asp to asp.net.
Asp had absolutely no strictness at all at compile, ever error was
detected at runtime.

I am not only referring to Microsoft's products for Web development. They
are only a small part of the whole business.

 

[Tom Shelton]

Well, I do not see a problem here. I have never seen a problem arising from
how VB works regarding string value comparisons, and I have seen a lot of VB
code.

I concure. I've seen and worked with lots of VB code, and never found it an
issue.

Just take a look at the third event syntax definition:

Event Statement
<URL:http://msdn.microsoft.com/en-us/library/6hwhs172.aspx>

VB supports customization of 'RaiseEvent', which is not supported by C#.

Since, you have full control of the event and backing store - I'm not sure how
having a customization of raiseevent helps in C#? I can see it in VB, becasue
of the RaiseEvent kewyord - but, C# has no such animal. In C#, you would simply
create a class method:

protected virtual void RaiseXEvent (MyEventArg type)
{
// do custom event logic here
}

Well, I consider the C# semantics rather useless because they "break basic
laws of logic and mathematics", as Bill McCarthy says:

C# defies logic - @ Head


I am not only referring to Microsoft's products for Web development. They
are only a small part of the whole business.

There is definately a lot of interest in dynamic programming languages, such
as ruby, python, etc.

 

[Martin H.]

Hello Michael,

Well it is something that would confuse beginners (if nothing did not equal
"") and it does make it easier for someone to start programming. On the
other hand the expert says WTF, why does this particular data type behave
differently to every other data type in the language.

If that person who says the WTF stuff was an expert he would know that
in BASIC (note that there is no Visual) there are no objects. There are
only Integers, Single/Double and Strings. And since there are no
objects, there is no Nothing. In BASIC a variable which has been defined
gets a default value. Variables can be defined (even up to VB6) without
using Dim, just by using it.

10 IF a$="" THEN GOTO 30
20 PRINT "You don't get me..."
30 PRINT "End of program"
40 END

If you like, use this program with QBASIC and you will find that this
program works fine.

VB.NET broke with several traditions of BASIC (as well as the classic
Visual Basic did).

I still find myself sometimes typing something like
Open "I",#1,"Myfile.txt"
In good old AmigaBASIC/QBASIC this would open the file Myfile.txt.
I sometimes wish, that VB.NET had more BASIC in it. Well, I think I
start daydreaming again...

Best regards,

Martin

 

[Michael C]

Well, I do not see a problem here. I have never seen a problem arising
from how VB works regarding string value comparisons, and I have seen a
lot of VB code.

I doubt it has caused any problems but that doesn't mean it's not bad. The
language giving special treatment to 1 object is just bad. It makes me
wonder where else they have special handling of objects. It can be extra
hassle in C# but I prefer it that way to keep the consistancy.

Just take a look at the third event syntax definition:

Event Statement
<URL:http://msdn.microsoft.com/en-us/library/6hwhs172.aspx>

VB supports customization of 'RaiseEvent', which is not supported by C#.

See Tom's reply.

Well, I consider the C# semantics rather useless because they "break basic
laws of logic and mathematics", as Bill McCarthy says:

C# defies logic - @ Head
<URL:http://msmvps.com/blogs/bill/archive/2007/09/07/c-defies-logic.aspx>

Bill McCarthy? That troll from the VB6 newsgroups? While this does seem to
be a fault with C# it's fairly typical of the stuff that the hard core VBers
bring up. It's something that you will almost never encounter and could
easily go through your entire career without noticing. It seems a huge
stretch bringing something like this up. Compared to intellisense it
completely pales into insignificance.

I am not only referring to Microsoft's products for Web development. They
are only a small part of the whole business.

Fair enough, I don't do much web myself. I don't see how the industry could
not be moving more towards greater compile time checking. Considering it
started off as just html with all errors at runtime, where we are now is a
lot more strict than that.

Michael

 

[Herfried K. Wagner [MVP]]

I doubt it has caused any problems but that doesn't mean it's not bad. The
language giving special treatment to 1 object is just bad. It makes me
wonder where else they have special handling of objects. It can be extra
hassle in C# but I prefer it that way to keep the consistancy.

I prefer consistency too, but I accept a break of consistency if it makes
more sense.

See Tom's reply.

Providing a custom implementation of 'RaiseEvent' gives the ability to
control how the delegates in the event's delegate list are invoked. This
allows for conditional invocation of delegates in the list of delegates, for
example.

You'll find an illustrative sample here ("Custom events in VB.NET 8.0"):

Custom Events in VB.NET 2005

Bill McCarthy? That troll from the VB6 newsgroups? While this does seem to
be a fault with C# it's fairly typical of the stuff that the hard core
VBers bring up.

Instead of attacking the person, just counter his arguments.

It's something that you will almost never encounter and could easily go
through your entire career without noticing. It seems a huge stretch
bringing something like this up. Compared to intellisense it completely
pales into insignificance.

A break of the transitivity rule is IMO a significant design flaw which has
the potential to lead to erroneous behavior.

 

[Tom Shelton]

I prefer consistency too, but I accept a break of consistency if it makes
more sense.

Still not getting how this is a benifit in C#? A simple method in a C# class
accomplishes the exact same thing... The only difference is that you have to
make sure your class calls the method, because their is not equvialent to the
RaiseEvent keyord. The VB.NET method is essentially an overload of this (like
operator overloading).

In C#, I would just do:

protected virtual void RaiseXEvent ( /* maybe some args */ )
{
foreach (SomeDelegate d in myDelegateBackingStore)
{
if (someCondition)
d(/*maybe args*/);
}
}

Then when i wanted to raise it:

RaiseXEvent();

I'm not sure what the problem is here?

 

[Michael C]

I prefer consistency too, but I accept a break of consistency if it makes
more sense.

I don't think it makes much sense having nothing equal to something.

Providing a custom implementation of 'RaiseEvent' gives the ability to
control how the delegates in the event's delegate list are invoked. This
allows for conditional invocation of delegates in the list of delegates,
for example.

Surely you can do the same thing in C#. But again I must say this has got to
be a pretty obscure feature. I'll gladly swap this for C#'s intellisense. I
don't want to upset you but when you bring things up like this i get the
feeling you're digging as hard as you can to find things to make VB in your
mind superior to C#.

Instead of attacking the person, just counter his arguments.

Fair enough, although as you should have noted I did counter his arguements.

A break of the transitivity rule is IMO a significant design flaw which
has the potential to lead to erroneous behavior.

It is a problem but a problem which will almost never be encountered. If I
was doing a <= on 2 nullable values then the number 1 thought in my mind
would be what happens if one or both of them are null. I agree it is
possible a careless programmer might get caught out here but it's a pretty
far out possibility. Again I get the feeling you're digging for any faults
you can find.

Michael

 

[Michael C]

It is at least in sp1. Options->Tools-Text Editor->C#->Advanced, under
the
Editor Help section -> Show live semantic errors.

That's different to background compiling.

 

[Michael C]

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

Even when I was working in vb.net full time I never used it. Personally I
would prefer not to have it. When working in a team environment if there's
something that can be done wrong then someone will do it wrong.

In corporate environments I'd adjust the project templates to have 'Option
Strict' enabled by default.

But you can't enforce that in vb.net.

Michael

 

[Michael C]

Providing a custom implementation of 'RaiseEvent' gives the ability to
control how the delegates in the event's delegate list are invoked. This
allows for conditional invocation of delegates in the list of delegates,
for example.

Are you aware that C# supports the equivelent of addhandler and
removehandler keywords (called add and remove in C#)? As for the custom
implementation of raise event you can just create your own function and do
raise the event in any way you like in there. Although in 8 years of using
..net I can't say i've ever needed this feature.

Michael

 

[Tom Shelton]

That's different to background compiling.

Nope. It's background compiler. Google.

 

[Mike Williams]

I don't think it makes much sense having nothing equal to something.

It's all semantic gobbledegook anyway! It is not really nothing at all! It
is something, a memory location containing a value of zero, indicating that
it is pointing at nothing in particular, whereas in fact it is (except that
you know by convention that the location it is pointing to is not a location
which is normally used to store anything)! All semantic gobbledgook ;-)

Mike

 

[Herfried K. Wagner [MVP]]

Are you aware that C# supports the equivelent of addhandler and
removehandler keywords (called add and remove in C#)?

Sure, that's why I didn't mention it.

As for the custom implementation of raise event you can just create your
own function and do raise the event in any way you like in there. Although
in 8 years of using .net I can't say i've ever needed this feature.

Yes, you could do that, but the VB approach encapsulates the event-related
code better. You can still raise the event like any other event in VB and
yoi do not have to "hide" it in a method.

 

[Michael C]

Yes, you could do that, but the VB approach encapsulates the event-related
code better. You can still raise the event like any other event in VB and
yoi do not have to "hide" it in a method.

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. If you had other developers external to your class
raising events then maybe it would be useful.

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.

Michael