A VB.NET Critique

[Eric]

There is a VB.NET critique on the following page:
http://www.vb7-critique.741.com/
for those who are interested. Feel free to take a look and share your
thoughts.

Cheers, Eric.

Ps: for those on comp.programmin g, this may be off topic, but I've
posted there because the critique was part of a discussion in that
group.

[Eric]

sp*********@yah oo.com (Edward G. Nilges) wrote in message news:<f5******* *************** ****@posting.go ogle.com>...

Programmer Dude <Ch***@Sonnack. com> wrote in message news:<3F******* ********@Sonnac k.com>...

Just a couple random thoughts....
Eric wrote:
Very interesting ontopic and intelligent critique, Eric. Thank you.

Thank you Edward, for that vote of confidence :)

<snip>

I'm a big proponent of:

Dim c As Integer = 1 ' .....
Dim d As Integer = 2 ' .....
Dim e As Integer = 3 ' .....

Because it helps you to add documentation as to the purpose
of your variables. I also think it's easier to read and gives
you a better picture of how many locals you have.

I agree. One line per variable. If it is at all screwy as in the case
of a collection that is restricted to a type, add a comment:

Dim colCustomer As Collection ' Of type objCustomer

Actually, there is a now a way to enforce that assertion and ensure
that only objects of type objCustomer will go into that collection.
You create a wrapper around the Collection class, and do the checking
using the reflection facilities, every time an item is added to the
collection. This helps a little, but you still need to cast when
retrieving items from the collection. Later this year, all that will
be history because generics are coming to VB.NET :)

By way of logical deduction, the Is operator should work in all
cases because it works on object types and every type in
.NET is an object. The problem? It doesn't.

I don't agree it should. The sematics of the Is operator, AIUI,
is to compare, essentially, the "pointers". The semantics of
a non-object type are such it doesn't HAVE a "pointer".

I think it is well to make distinct the semantics of "equal VALUE"
and "equal references". Just MO.

Absolutely. While everything is an object, there is an important
distinction that would be hidden by allowing IS to take value types.

Furthermore, allowing Is to be applied to value types would provide a
useless facility for it would always have to return False. Each
instance of a Value type, even if it has the same value as another
instance, is a different object.

I agree. However since the implementers are already cheating about the
actual implementation of value types the same could be easily done for
the Is operator. I am not necessarily proposing that it be done, but
it would help consistency if it was. To the everyday programmer this
lack of consistency is a non-issue (and may be favourable as some
people's views indicate) but to the language designer, its food for
thought.
"Identity of indiscernables? " Give me a break. In terms of Leibniz'
metaphysics, two distinct variables have two different space time
coordinates by definition, unless the language allows aliasing as seen
in the outdated and unsafe language C. Yes we have AddressOf but for
specific reasons in specific contexts.
I'll have to read more on Leibniz's work, it sounds interesting.
Finally we get to the case of Nothing. Is Nothing, Nothing? By this
time the compiler writer has taken either to strong drink or
Heidegger.

LOL. The output of the following snippet seems to be in agreement:

If Nothing Is Nothing Then
MsgBox("The compiler writer took a stong drink.")
End If

Cheers,
Eric :)

[Eric]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message news:<MP******* *************** *@msnews.micros oft.com>...

Edward G. Nilges <sp*********@ya hoo.com> wrote:

<snip>

Absolutely. While everything is an object, there is an important
distinction that would be hidden by allowing IS to take value types.

<snip>

Actually, *not* everything is an object. Everything can be *converted*
to an object via boxing, but a value type value itself is *not* an
object.

Implementation wise, yes, but conceptually, no. See response to Programmer Dude.
Cheers,
Eric :)

[Eric]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message news:<MP******* *************** *@msnews.micros oft.com>...

Eric <er********@ema il.com> wrote:

This is going to be an interesting problem area of the .NET CTS
resulting from the difficult (and in some ways, pointless) goal of
type unification. Everything in .NET (and hence VB7) *is* an object
because all types either directly or indirectly inherit from Object.
If you agree with me so far, then you will also agree that *all* types
in .NET are actually *reference* types its just that *some* of those
reference types (those that inherit from ValueType) have *value
semantics*.
No, *not* everything in .NET is an object. Not everything in .NET is a
reference type.

I can see where you're coming from, but you're wrong. I believe section
8.2.4 of the ECMA spec is the relevant bit:

<snip long quote from ECMA spec>

The important bit of 8.9.7 is:

<quote>
Value types do not support interface contracts, but their associated
boxed types do.
A value type does not inherit; rather the base type specified in the
class definition defines the base type of the boxed type.
</quote>

A look a the class hierarchy via the object browser in VS.NET,
apparently shows that System.ValueTyp e inherits from System.Object.

Cheers,
Eric :)

[Jon Skeet [C# MVP]]

Edward G. Nilges <sp*********@ya hoo.com> wrote:

I can see where you're coming from, but you're wrong. I believe section
8.2.4 of the ECMA spec is the relevant bit:
OK, this denies that the value is an object from the standpoint of the
spec. And I agree that you cannot inherit a value type.

Nonetheless, value types Inherit from object.

No, the *boxed* types inherit from object (via ValueType). This *is* an
important distinction.
I think there's a real danger here of a Scholastic and pointless
discussion of what is and is not an object. I'd point out that C
experts CLAIM that their values are objects.

I'd say the hell with it. Who cares. Use the value right and vaya con
dios.

But you are saying that to be an object the type must have a reference
type. Doesn't this mean that it's wrong to speak of value objects? OK,
but then why do values have properties and methods?
I'll agree that it's difficult in terms of terminology, but I think
it's worth being clear on it where possible. The value "5" for instance
(as a bit pattern), has no actual type, even if you know the length -
if it's a 32 bit "5" it could be an int32, a uint32 or a single, as the
says. The value itself is not an object - but methods can be called on
the boxed type which act on a value *as if* the value is an object.
I think an overly Scholastic reading would make for poor pedagogy.

Whereas I think that an overly "loose" reading where everything's a
reference type when it clearly isn't makes for poor understanding and
communication.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Eric <er********@ema il.com> wrote:

Actually, *not* everything is an object. Everything can be *converted*
to an object via boxing, but a value type value itself is *not* an
object.

Implementation wise, yes, but conceptually, no. See response to Programmer Dude.

No, conceptually not everything is an object either. Please read the
quotes from the spec *very carefully* - preferrably reading them in the
context of the rest of the spec as well.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Eric <er********@ema il.com> wrote:

The important bit of 8.9.7 is:

<quote>
Value types do not support interface contracts, but their associated
boxed types do.
A value type does not inherit; rather the base type specified in the
class definition defines the base type of the boxed type.
</quote>

A look a the class hierarchy via the object browser in VS.NET,
apparently shows that System.ValueTyp e inherits from System.Object.

Please read the quote again, carefully. The type System.Int32, for
instance, isn't the actual type of an integer - it's the *boxed* type
of an integer.

Can you not see how what you're saying is going against what the spec
says?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Eric]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message news:<MP******* *************** **@msnews.micro soft.com>...

Eric <er********@ema il.com> wrote:

Fair enough. I honestly dont find this behaviour logical and simple:

Dim arr1() As Integer
Debug.Assert(ar r1.Length = 0) 'exception thrown here

Dim arr2() As Integer = {}
Debug.Assert(ar r.Length = 0) 'no exception thrown here

but again, opinions differ.
It makes perfect sense. The first one has defined a variable of type
"reference to array of integers", and has implicitly set the value to
nothing.

The second one has defined a variable of type "reference to array of
integers", and has explicitly set the value to be a reference to an
empty array.

The reason I personally think its not logical...hmm, actually it is
logical, its just not friendly so to speak. Simply defining the
default value of an array to be a zero length array, such that:

Dim arr1() As Integer

is synonymous with:

Dim arr1() As Integer = {}

would, IMO, be more practical.

My complaint is geared towards some of the
types being half way between the value-type and reference-type
categories

Arrays are reference types in all respects - how are they "half way" to
being value types?

For instance, you are not required to use the New operator and can do:

Dim arr() As Integer = {1, 2, 3}

instead of:

Dim arr() As Integer = New Integer() {1, 2, 3}

This absence of New in the first syntax gives no indication that
arrays are indeed reference types and are allocated on the heap. It
makes it appear as if arrays are stack allocated and are hence value
types. A similar thing can be said about the New operator and
structures.

My reasoning for this is based on my understanding of the semantics of
the New operator both from VB6 and other OOP languages like C++ and
Java, but YMMV.

(Note: that syntactical allowance is done for convenience and I am
glad its allowed. For other syntactical exceptions that have to be
done to make type unification viable, see concepts such as "manifest
classes" in section 3.3 of the Blue language paper at
http://tinyurl.com/yryyz )

which is one of the unfortunate side-effects of the goal
of type unification. The basis for my complaint about the Length
property is given in the "Arrays as objects" section:

"I now have to worry about null references while am using arrays. For
instance, the Length property should logically contain zero when an
array has no elements. However, because a reference to an array
without elements is a null reference, I can't check the Length of an
uninitialised array without getting a NullReferenceEx ception. If
arrays were not objects or the compiler was kind enough to 'cheat' and
return 0 for the expressions like "MyArray.Length " when MyArray was
null, I could retrieve certain info (array length, number of
dimensions and upper bounds of each dimension) without ever worrying
about null references."

Yes, but if arrays weren't objects there's be any number of other
problems with them. Passing them around would be a nightmare, for
instance - you'd have to pass them by reference all over the place just
for the sake of performance. Yuk.

I agree but there is a way to implement them to satisfy both the
performance criteria and the avoidance of NullReferenceEx ception.
There are two parts to an array. The descriptor, which contains type
information on the array (number of dimensions, size of each
dimension, pointer to data, etc) and the actual array data. If you
allocate the descriptor on the stack and the data on the heap the
problem vanishes. One can check the array type info without getting
exceptions because the descriptor is stack allocated, and passing them
around can be defined as copying the descriptor rather than the data
hence removing the performance penalty.

Furthermore, since ReDim can't change the number of dimensions for an
array in VB.NET, the above proposal of stack allocating the descriptor
works well. In VB6, the descriptor would need to be allocated on the
heap (due to ReDim's behaviour) otherwise the compiler writer will
need some serious black magic to implement dynamic allocation within
the current procedure's stack frame.

Properties such as the number of dimensions, the upper bound of each
dimension and the length of an array should be things that you can
find out whether the array has elements or not.

Unless there is an array, there *is* no upper bound though - and an
array always has all its possible elements, even if some of them are
null/nothing. In your previous example, arr1.Length wasn't saying "what
is the length of the array which is arr1's value", it's saying "what is
the length of the array which arr1's value refers to" - and given that
arr1's value *doesn't* refer to an array, it's natural that there
should be an exception.

Natural? Yes. Convenient and efficient? Not IMO. (See previous
comments in this same post).
It's important to distinguish between the idea of the value of a
variable being an actual array (which it isn't) and it being either a
reference to an array, or nothing.
Agreed. One thing though: it can be quite convenient if the variable
is the actual array (i.e the array descriptor and data are stack
allocated) and the performance gains for small, fixed-size arrays
(such as the 3x3 transformation matrices used in graphics programming)
can be very substantial.
You shouldn't usually be really *worrying* about
NullReferenceEx ceptions though - either null is a valid value for the
variable at that point in time, in which case it may well have a
special meaning as distinct from an empty array, or it may not be
valid, in which case throwing an exception is perfectly reasonable
(although you may wish to make the check at the start of the method if
it's coming in as a parameter, for instance).

You are right that I shouldn't have to be worrying about
NullReferenceEx ceptions but with the current implementation, I have
no choice but to worry. Even if I do check incoming parameters,
VB.NET doesn't allow declarations of fixed-size arrays and I can wipe
out the array at any time and later get into trouble:

Sub Bar(ByVal arr() As Integer)
If arr Is Nothing Then
'take appropriate action
End If

'some code here

Erase arr

'some more code here

For n As Integer = 0 To arr.Length - 1
'blah
Next
End Sub

The For loop fails with a NullReferenceEx ception because of using the
Length property on a null object. To avoid that, I either have to
ensure that an array is never wiped out (an endeavour that will fail
atleast once) or litter my code with "If" statements to check for the
possibility each time I want to access an instance member of the Array
class.

but it seems like half of
the essay stems from a total misunderstandin g of .NET types

I am human and hence prone to being wrong, but I can confidently say
(without meaning to sound haughty) that I have a fairly good if not
firm understanding of the .NET type system.

Given the above (and my previous post), I'm afraid I have to disagree
with you. The suggestion that all types are reference types is the
biggest problem, IMO.

I should have been clearer initially, about the conceptual and
implementation aspects when giving my explanation. My bad.

Cheers,
Eric :)

[Jon Skeet [C# MVP]]

Eric <er********@ema il.com> wrote:

That is what I believe Daniel is getting at in his response when he
says native types are not objects. From an implementation point of
view, he is correct and native types (or "value types" in .NET
parlance) are not reference types and dont behave like objects. But
*conceptually*, if you apply the definition of inheritance in OOP an
Integer for instance, is a reference type:
<snip>
If my logic can be proved unsound, then I will stand corrected.

Your logic is unsound because although the *boxed* type for Integer
does indeed inherit from object, the value type itself doesn't, and
can't. As the specification says, value types themselves *do not*
inherit - only their boxed types do.

Now, whether "System.Int 32" (Integer) is the boxed type or the value
type itself seems a bit confused, and seems to depend on context. This,
I'll readily agree, is a pain when trying to be precise about these
things.
The specification states that the class definition is used to define
both of them.

The specification *is* very clear, however, that not everything is an
object type, or a reference type. It even says explicitly "Value types
are not object types".

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Eric <er********@ema il.com> wrote:

It makes perfect sense. The first one has defined a variable of type
"reference to array of integers", and has implicitly set the value to
nothing.

The second one has defined a variable of type "reference to array of
integers", and has explicitly set the value to be a reference to an
empty array.
The reason I personally think its not logical...hmm, actually it is
logical, its just not friendly so to speak. Simply defining the
default value of an array to be a zero length array, such that:

Dim arr1() As Integer

is synonymous with:

Dim arr1() As Integer = {}

would, IMO, be more practical.

What would

Dim arr1() As Integer = Nothing

do then? If it would create a variable with an initial null reference
value, then you still haven't bought much as array type expressions can
still be null and you can still get NullReferenceEx ceptions. Indeed,
you'll have that problem anyway as other languages *do* allow array
type expressions to be null.

When is it actually practical to use an array type variable without
assigning a reasonable value to it anyway? I would argue that actually
using the value of arr1 when it's only been declared as

Dim arr1() As Integer

and hasn't had an explicit value assigned to it yet is almost always
going to be incorrect program logic anyway.

Arrays are reference types in all respects - how are they "half way" to
being value types?

For instance, you are not required to use the New operator and can do:

Dim arr() As Integer = {1, 2, 3}

instead of:

Dim arr() As Integer = New Integer() {1, 2, 3}

This absence of New in the first syntax gives no indication that
arrays are indeed reference types and are allocated on the heap. It
makes it appear as if arrays are stack allocated and are hence value
types. A similar thing can be said about the New operator and
structures.

Ah, right. Yes, the language here is hiding the fact that it's a
reference type to some extent - but it still *is* a reference type,
entirely.
My reasoning for this is based on my understanding of the semantics of
the New operator both from VB6 and other OOP languages like C++ and
Java, but YMMV.
Array types are reference types in Java as well, but the following is
perfectly legal:

public class Test
{
public static void main(String[] args)
{
String[] test = {"hello", "there"};
for (int i=0; i < test.length; i++)
{
System.out.prin tln (test[i]);
}
}
}

Again, no new but the array itself is on the heap. It's just a common
syntactical allowance.
(Note: that syntactical allowance is done for convenience and I am
glad its allowed. For other syntactical exceptions that have to be
done to make type unification viable, see concepts such as "manifest
classes" in section 3.3 of the Blue language paper at
http://tinyurl.com/yryyz )
Right - but it *is* only a syntactical allowance, and doesn't in any
way show the type system *itself* to have "half-way" types.

Yes, but if arrays weren't objects there's be any number of other
problems with them. Passing them around would be a nightmare, for
instance - you'd have to pass them by reference all over the place just
for the sake of performance. Yuk.

I agree but there is a way to implement them to satisfy both the
performance criteria and the avoidance of NullReferenceEx ception.
There are two parts to an array. The descriptor, which contains type
information on the array (number of dimensions, size of each
dimension, pointer to data, etc) and the actual array data. If you
allocate the descriptor on the stack and the data on the heap the
problem vanishes. One can check the array type info without getting
exceptions because the descriptor is stack allocated, and passing them
around can be defined as copying the descriptor rather than the data
hence removing the performance penalty.

Interesting idea, although I'll need to think about it further before
necessarily agreeing it would be a *good* idea. Of course, you could
implement that yourself quite easily as a value type which contained an
array. Until generics come in, you'll have to create a different type
for each array type you want, of course.

I'll think about that some more. I *think* I actually rather like being
able to tell the difference between a 0-length array and a null
reference though.

Also, if array types were value types, people would expect them to
*act* like value types, so you could pass them with impunity and not
have the values inside them change. That wouldn't be true with your
system. Value types which contain mutable reference types always seem a
bad idea to me, just in terms of having misleading semantics. I guess
we could get used to it for arrays in the same way we have with the
different syntax for constructing them.

Properties such as the number of dimensions, the upper bound of each
dimension and the length of an array should be things that you can
find out whether the array has elements or not.

Unless there is an array, there *is* no upper bound though - and an
array always has all its possible elements, even if some of them are
null/nothing. In your previous example, arr1.Length wasn't saying "what
is the length of the array which is arr1's value", it's saying "what is
the length of the array which arr1's value refers to" - and given that
arr1's value *doesn't* refer to an array, it's natural that there
should be an exception.

Natural? Yes. Convenient and efficient? Not IMO. (See previous
comments in this same post).

It's reasonably efficient, I believe, and it *does* have the
convenience of allowing you to distinguish between null and an empty
array.

It's important to distinguish between the idea of the value of a
variable being an actual array (which it isn't) and it being either a
reference to an array, or nothing.

Agreed. One thing though: it can be quite convenient if the variable
is the actual array (i.e the array descriptor and data are stack
allocated) and the performance gains for small, fixed-size arrays
(such as the 3x3 transformation matrices used in graphics programming)
can be very substantial.

But then you have horrendous problems with large arrays. I think all in
all I'm much happier with them being reference types.

You shouldn't usually be really *worrying* about
NullReferenceEx ceptions though - either null is a valid value for the
variable at that point in time, in which case it may well have a
special meaning as distinct from an empty array, or it may not be
valid, in which case throwing an exception is perfectly reasonable
(although you may wish to make the check at the start of the method if
it's coming in as a parameter, for instance).

You are right that I shouldn't have to be worrying about
NullReferenceEx ceptions but with the current implementation, I have
no choice but to worry. Even if I do check incoming parameters,
VB.NET doesn't allow declarations of fixed-size arrays and I can wipe
out the array at any time and later get into trouble:

Sub Bar(ByVal arr() As Integer)
If arr Is Nothing Then
'take appropriate action
End If

'some code here

Erase arr

'some more code here

For n As Integer = 0 To arr.Length - 1
'blah
Next
End Sub

The For loop fails with a NullReferenceEx ception because of using the
Length property on a null object.

Absolutely - and you want it to, IMO, as it's showing a bug in your
code.
To avoid that, I either have to
ensure that an array is never wiped out (an endeavour that will fail
atleast once)
So you'll get an exception to show that you've got a bug in your code.
That's what exceptions are for. This is better than the language
masking the fact that you've made a mistake and just silently running
an empty loop effectively.
or litter my code with "If" statements to check for the
possibility each time I want to access an instance member of the Array
class.

No, you don't want to do that unless you know that null/Nothing is a
valid value for the variable at that time. If it is, you need to be
checking it anyway. If it's not, you should get an exception so you can
find out where the problem is. Otherwise it would be like FileStream
not failing if you ask it to open a file which doesn't exist, and
instead returning an empty stream - it masks errors rather than helping
you to fix them.

Given the above (and my previous post), I'm afraid I have to disagree
with you. The suggestion that all types are reference types is the
biggest problem, IMO.

I should have been clearer initially, about the conceptual and
implementation aspects when giving my explanation. My bad.

I'm afraid I still think you're wrong - the spec clearly states that
not all types *are* reference types, conceptually as well as in
implementation.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Eric]

er********@emai l.com (Eric) wrote in message news:<ca******* *************** ***@posting.goo gle.com>...

David <df*****@127.0. 0.1> wrote in message news:<sl******* *************@w oofix.local.dom >...
<snip lotsa stuff>
I will quote myself from another group, to show my reasoning behind
that argument:

<quote start>

This is going to be an interesting problem area of the .NET CTS
resulting from the difficult (and in some ways, pointless) goal of
type unification. Everything in .NET (and hence VB7) *is* an object
because all types either directly or indirectly inherit from Object.
If you agree with me so far, then you will also agree that *all* types
in .NET are actually *reference* types its just that *some* of those
reference types (those that inherit from ValueType) have *value
semantics*. Now then, the Is operator checks if two variables refer to
the same object. By way of logical deduction, the Is operator should
work in all cases because it works on object types and every type in
.NET is an object. The problem? It doesn't. While it is easy to accept
that and just work with it, the issue is still a consistency problem
from a language design point of view and is of more relevance to those
interested in language design. Such exceptions have to be made all the
time when one attempts type unification. Other examples abound in .NET
but to see this in a different language look at this article on the
Blue language (especially section 3.3): http://tinyurl.com/yryyz

<quote end>

Realising the number of languages on .NET and the different wording in
the specs for each of those languages, I would like to reduce the
scope of my statement given above:

"...Everyth ing in .NET (and hence VB7) *is* an object because all
types either directly or indirectly inherit from Object..."

and narrow it down to VB.NET rather than the whole of .NET. It may
still apply to the other languages, but I am not going to gamble on
that by making a potentially wrong all-encompasing statement.

<snip lots more>
Cheers,
Eric :)