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.

[Cor]

Hi Programmer Dude,

I write this for Eric but I think this is the best place and Eric deserves
to get reaction.

I agree with you.

Cor

[Jon Skeet [C# MVP]]

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:

<quote>
For every Value Type, the CTS defines a corresponding Reference Type
called the boxed type. The reverse is
not true: Reference Types do not in general have a corresponding Value
Type. The representation of a value of
a boxed type (a boxed value) is a location where a value of the Value
Type may be stored. A boxed type is an
object type and a boxed value is an object.
All Value Types have an operation called box. Boxing a value of any
Value Type produces its boxed value, i.e.
a value of the corresponding boxed type containing a bit copy of the
original value. All boxed types have an
operation called unbox. Unboxing results in a managed pointer to the
bit representation of the value.
Notice that interfaces and inheritance are defined only on Reference
types. Thus, while a Value Type definition
(see clause 8.9.7) can specify both interfaces that shall be
implemented by the Value Type and the class
(System.ValueTy pe or System.Enum) from which it inherits, these apply
only to boxed values.
</quote>

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>

--
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:

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.
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?
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.
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.

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.

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).

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.

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

[Edward G. Nilges]

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.

At the end of the day, I guess one could just
settle for typing a few more characters and use this:

Dim c As Integer = 1, d As Integer = 2, e As Integer = 3
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

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.

"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.

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.

[David]

On 2004-01-08, Eric <er********@ema il.com> wrote:

David <df*****@127.0. 0.1> wrote in message news:<sl******* *************@w oofix.local.dom >...

Focusing on the differences, natch...

starting with the Syntax section.

It seems this section has recieved the most attention in many
responses. It is hardly surprising since syntax is where a lot of
things are subjective.

Well, it's also the only section that's really fleshed out. The Semantic
and OOP sections are tiny, and the Type section is basically just
arrays and strings and contains a lot of redundancy. In fact, probably
80% of the entire 4-section essays really comes down to two basic
points:

1. You don't like the reference type/value type/boxing thing.

2. You believe certain types, like strings and arrays, shouldn't be
nullable.

The Is operator tests whether two references are identical, it makes
absolutely no sense to allow it to apply to value types. Really, that's
just not understanding what a value type is. And as for TypeOf, again
it makes absolutely no sense to apply to a value type; there is simply
no possible reasonable use of such a feature. Should the language still
allow programmers to do nonsensical things for the sake of completeness;
maybe, but that's exactly what you're ranting *against* when you
complain about the fact that Sub Main can be recursive. Make up your
mind.

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*.

See, that's the thing. They *aren't* reference types. As Jon Skreet
mentions in another post, the .Net spec makes that clear. And
unfortunately, it's this difference that underlies an awful lot of what
follows below. But you consistently repeat something like the above
paragraph, and I can take that in two ways; either you really don't
understand the type system, or you do understand it (as you say you do)
and you're using paragraphs like the above as a rhetorical style to
emphasize what you see as inconsistencies in that system.

Now, if you're saying that the boxing mechanism is confusing and
inelegant, fine, then say it. In fact, I'd agree. All this stuff about
how something is a value type but is boxed and becomes a reference type
is indeed, IMHO a bit confusing and inelegant. However, I also think
it's incredibly useful.
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
Once you drop your idea that everything's a reference type, this
argument fades away. When used on a value type, the only reasonable
semantics would have Is always return false (because two value-type
variables are never the same thing). And as you say yourself,
IMO, unnecessary flexibility
is just as bad as no flexibility.

And if you really think
Dim p as Point = {12,15}
is much simpler and easier to read than
Dim p as New Point(12, 15)
then I'm kinda glad you don't do language design.
:) It being easier to read is again subjective and my exposure to
C/C++ seems to be showing here (and yes, I know VB isn't C/C++ and nor
should it be).

I doubt that's the difference. I started with C, then C++ when I
started programming.
However, as for it being *simpler* (a notion which is
still subjective but one that is easier to give arguments for or
against) I said the following:

"...the variation I am suggesting, is conceptually simpler, IMO. With
the current syntax you have to understand constructors and their
semantics, use of the 'New' keyword both in variable declarations and
definitions of constructors, and finally, use of named arguments."
Actually, named arguments aren't really necessary in the example (I
realize you had another example which used them).
Opinions will differ, so it would be nice if someone can find and
present arguments that show it not to be simpler, so we can have
atleast two points of view to consider.

You're right, I didn't really make an argument there, largely because I
simply disliked the look of the syntax. But the problem is that while
your syntax seems to work fine for a simple point, there's a lot of
problems once things get more complex. As one simple example, it's very
counterintuitiv e to have declaration order determine construction
semantics; very few other languages work this way, and classes in VB.Net
and VB6 don't work this way.

Public Structure Rect
Public Left as integer
Public Top as Integer
Public Right as integer
Public Bottom as integer
Public Width as Integer
Public Height as integer
End Structure

OK, a few months later, someone decides to clean that up a bit so that
horizontal measurements are grouped together...

Public Structure Rect
Public Left as integer
Public Top as Integer
Public Width as Integer

Public Right as integer
Public Bottom as integer
Public Height as integer
End Structure

Under your scheme, every new rectangle declaration just broke, and broke
silently. Now, you also have positional parameters in function calls
and constructors, but that's pretty common across languages and even
beginning programmers understand that. Making the relative positions of
variable declarations semantically important is not common (yes, it pops
up occasionally, like in dtor order in C++, but it's pretty rare).

>You cannot declare an optional parameter which is of a structure type.

> Public Sub Foo(Optional Arg As SomeStructure = Nothing)

> 'this wont compile
> Why the limitation, when the above makes perfect sense?

Because the above doesn't make perfect sense, in fact it makes
absolutely no sense at all.

Could you perhaps expand a little on your point of view? Given what
the language reference says about the Nothing keyword:

"The Nothing keyword represents the default value of any data type.
Assigning Nothing to a variable sets it to the default value for its
declared type. If that type contains variable members, they are all
set to their default values."

Actually, I didn't know that. Passing Nothing as a value type seems
nonsensical to me, but you're right. If the language accepts it in one
place it should accept it in another.

I'll zoom through a few other things. First, .Length in arrays and
.Count in collections aren't measuring the same thing, and it would be
much more confusing if two properties with such different meanings had
the same name.

They have different meanings? Thats not the impression I get when I
read the documentation of those respective properties:

So, the docs suck. Not uncommon in VB.

Dim a1(10) as string
Dim a2 as New ArrayList(10)

For i as integer = 0 to 5
Dim s as string = "Hello " & i.ToString()
a1(i) = s
a2.Add(s)
Next

' What is the capacity of my array
Console.WriteLi ne(a1.Length.To String())

' How many items have I added to my ArrayList
Console.WriteLi ne(a2.Count.ToS tring())

..Net is consistent in keeping those difference clear, and that's very
useful in terms of daily programming.

The constant complaints that objects must be initialized
(such as arrays and strings) just eludes me somewhat; I honestly find
the behavior to be perfectly logical and simple.

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. My complaint is geared towards some of the
types being half way between the value-type and reference-type
categories, which is one of the unfortunate side-effects of the goal
of type unification.

Array declaration is a mess in all kinds of ways, but I don't see the
value-type/reference-type issue here. Rather, both arrays and strings
are reference types, but because they're so common there's a special
shortcut syntax for initialization. Would the language be cleaner
without the shortcut syntax? Sure, but the shortcut is useful.

You complain about some kind of halfway state, but that's exactly what
you're arguing for throughout the entire array section. After all, you
don't *really* want arrays to be value types (I hope not at least,
because there's all kinds of good reasons not to do that), but you want
them to auto-initialize like value types. Your proposals here sound
good at first glance, yes checking for null is a pain, but they create
an incredibly inconsistent class.

--
David
dfoster at
hotpop dot com

[Jon Skeet [C# MVP]]

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.

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

[Eric]

"Cor" <no*@non.com> wrote in message news:<u2******* *******@TK2MSFT NGP10.phx.gbl>. ..

Hi Eric,
Hi Cor, thank you for taking some time to read the critique.

It looks very much written from a personal view.
Yes, quite a number of points are subjective and different people will
have different opinions.
Although there are elements in it that can be thought about are there also
elements that has been discussed here also and have been criticized here,
but have an understandable reason by instance arrays and collections.
Yes, some issues are new and (to the best of my knowlegde) haven't
been discussed before and others would have been discussed in various
places, especially during the Beta period of VS.NET.
You are able to give your comments to the VB.net development group. There
are many chats in with you can participate. Serious things (and even stupid
things) are there normally threaten seriously.
True. Paul Vick was one of the first people to recieve the critique
and he forwarded it onto the rest of the VB.NET team. He is on holiday
right now until February, so it wont be until then that we can have
discussions about it with him and the rest of the team.
An example of that what it makes a personal view is this. You are talking
about UK date format, are you talking in future about the US measure system
(miles) and the UK measure system (meters)?
I'm not quite sure what you mean there. However, with regards to the
date formats, there is a genuine problem with date literals being
fixed to US format. This snippet shows this:

Dim d As Date = #3/2/2003#

Dim cul As System.Globaliz ation.CultureIn fo
cul = System.Globaliz ation.CultureIn fo.CurrentCultu re

System.Console. WriteLine("Your locale is: " & cul.DisplayName )
System.Console. Write("But the 3/2/2003 is intepreted to be in ")

If d.Month = 2 Then
'in the UK and some other countries the month
'comes after the day.
System.Console. Write("UK format.")
Else
'in the US (and some other countries?) the month
'comes before the day.
System.Console. Write("US format.")
End If

On my machine here in the UK, the above produces the following output:

Your locale is: English (United Kingdom)
But the 3/2/2003 is intepreted to be in US format.

My proposal in the critique is that there should be away to make the
date literal format locale independent, *not* that it be changed to
suit programmers used to the dd-mm-yy format. I suggested adding
another Option directive so the programmer can indicate what format
their date literals are in, but some didnt like that proposal. I'm not
so much concerned about *how* it is achieved, just that it be achieved
at all.

This week for instance, I had a real party trying to fix the web-based
MIS (Management Information System) at my place of work because half
the system (the front-end) was using dates in dd-mm-yy format and the
other half (the back-end) was using dates in the mm-dd-yy format. The
server was updated with service packs, and apparently logging on
interactively at the Windows 2000 Server console, resets the locale to
"English (United States)". As a result, all client s were using the UK
locale settings and the server was using the US locale settings. When
dates crossed over from client-side scripts to server side scripts,
chaos would result. I imagine the same problems would happen if you
ever have say an open source VB project, where some code is being
written in countries using the dd-mm-yy format and other code in
countries using the mm-dd-yy format.
Just my thoughts
Thank you for sharing them :)
Cor

Cheers,
Eric.

[Edward G. Nilges]

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.

Your terminological structure is unfamiliar to me, but I think you're
wrong. No, everything is an object because it Inherits,Object .

Boxing makes reference from a value type.

[Edward G. Nilges]

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:

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.

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 think an overly Scholastic reading would make for poor pedagogy.


<quote>
For every Value Type, the CTS defines a corresponding Reference Type
called the boxed type. The reverse is
not true: Reference Types do not in general have a corresponding Value
Type. The representation of a value of
a boxed type (a boxed value) is a location where a value of the Value
Type may be stored. A boxed type is an
object type and a boxed value is an object.
All Value Types have an operation called box. Boxing a value of any
Value Type produces its boxed value, i.e.
a value of the corresponding boxed type containing a bit copy of the
original value. All boxed types have an
operation called unbox. Unboxing results in a managed pointer to the
bit representation of the value.
Notice that interfaces and inheritance are defined only on Reference
types. Thus, while a Value Type definition
(see clause 8.9.7) can specify both interfaces that shall be
implemented by the Value Type and the class
(System.ValueTy pe or System.Enum) from which it inherits, these apply
only to boxed values.
</quote>

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>

[Eric]

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

Just a couple random thoughts....
I recall you were in the C# discussion on this group

http://tinyurl.com/yqyzq

where I had mentioned that I was compiling the critique. Thanks for
taking some time to read it :)
Eric wrote:

At the end of the day, I guess one could just
settle for typing a few more characters and use this:

Dim c As Integer = 1, d As Integer = 2, e As Integer = 3
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.

Yes, I tend to do that on ocassion too. However for local variables I
only do that if the purpose of the variable is not easily evident in
its name and only if there not too many variables otherwise the code
becomes too vertically long. For fields in structures/classes however,
I use your technique all the time.

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

I just started reading about C# last month and then set it aside
for other matters, but isn't it true the native types in C# do
NOT inherit from Object? If that's so, perhaps therein lies the
motivation?

See that's the thing about type unification - it has to make several
exceptions in order to be viable. With type unification (seen in
languages that subscribe to the "everything is an object" philosphy),
native types *conceptually* inherit from Object and are *conceptually*
objects by way of the "is-a" relationship as is defined by the concept
of inheritance.

However for type unification to be at all practical and efficient,
compiler writers have to resort to trickery, and *implementation *
wise, native types are *not* objects (they are allocated on the stack,
have copy semantics, do not require initialisation via constructors
and the new operator, etc).

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:

1. Type Integer in VB.NET is 32 bits and is mapped to the type
System.Int32

2. System.Int32 is a structure and inherits from the abstract class
System.ValueTyp e.

3. System.ValueTyp e is an abstract class and inherits from
System.Object.

4. Types that inherit from System.Object are considered reference
types.

5. If Integer is mapped to Int32 and Int32 is a ValueType and a
ValueType is an Object, then by transistive association, Integer is an
Object.

6. If Integer is an Object (as shown by step 5) and all child classes
of Object are reference types (as shown by step 4) then Integer is a
reference type.

So *conceptually* Integer is a reference type, but implementers have
to 'cheat' for efficiency reasons and *implementation wise*, Integer
doesnt behave like other objects. This is one of the biggest issues
with the goal of type unification.

If my logic can be proved unsound, then I will stand corrected.
C# does seem to have some "gotchas" with regard to the semantics
of native vs: object types.
I don't know the specifics with C#, but that will tend to be the case
with any language that tries to achieve type unification. For instance
I read in a paper ( http://www.heinzi.at/texte/smalltalk.pdf ) that
Smalltalk 16 bit signed integers can only actually represent 15 bit
signed values. This was due to an implementation trick to allow
equality testing to work properly for SmallInteger objects (see
section 3.1 "Object Memory", of the paper)

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.
I agree with you and you are right, but it just goes to show the
consistency problems that arise with type unification being promoted
as a conceptual but not implementation goal.
Regarding:

*Array.Length
...
*ICollection.Co unt

Arrays are Lists are quite distinct types, although languages like
VB can blur that distinction somewhat.

Consider that .Length and .Count can be DIFFERENT in an array,
but not (in almost all normal cases) in a collection. What I mean
is that an array might have a .Length of 50, but only a .Count of
10 items (the rest set to Nothing). Because reallocating an array
is expensive, it's not an uncommon technique.

True. Perhaps perceptions differ, but when I think of .Length or
..Count I am concerned with the total number of valid indexes that can
be used to access items which in turn indicates the total number of
items in the array/collection. Whether those items are set Nothing or
not, is only of concern when I am *using* the items, not when I am
trying to *access* the items.
Cheers,
Eric :)