Re: A VB.NET Critique

From: David (dfoster_at_127.0.0.1)
Date: 01/09/04 

Date: Thu, 08 Jan 2004 20:12:25 -0800

On 2004-01-08, Eric <ericmuttta@email.com> wrote:
> David <dfoster@127.0.0.1> wrote in message news:<slrnbvho8j.44s.dfoster@woofix.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
counterintuitive 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.WriteLine(a1.Length.ToString())

' How many items have I added to my ArrayList
Console.WriteLine(a2.Count.ToString())

.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(arr1.Length = 0) 'exception thrown here
>
> Dim arr2() As Integer = {}
> Debug.Assert(arr.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

Relevant Pages

  • Re: returning a char array
    ... setup and what would the declaration look like? ... It would be set up in a language other than C, ... arrays, period. ... I have a function that opens a file that I am trying to open that will ...
    (comp.lang.c)
  • Re: Some Questions Asked in Interview
    ... > you cannot use two dimensional arrays in C without using pointers to ... programs use non-trivial language parsers. ... I, like Thomas, have never to my knowledge used a declaration of the ... As he says, pointers to arrays ...
    (comp.lang.c)
  • Re: Declarative constraints in practical terms
    ... In the constraints can be expressed declaratively ... language which can only state *what* the ... Virtually all industrially used languages however (such as Java) ... have to translate it into a declaration, ...
    (comp.databases.theory)
  • Re: Boxing and Unboxing ??
    ... feature is worth the additional complexity it adds to the language. ... incurring boxing overhead and while maintaining compile-time type ... the programmer will not even need to know the difference. ... architecture can still have separate reference types and value types, yet, this ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C# Nullable types
    ... of an unassigned value (for reference types) apply to 0 for int ... that the compiler assigned it to. ... With the advent of higher-level programming languages, more abstraction away ... about using human language, as the abstractions approximate human ideas. ...
    (microsoft.public.dotnet.framework)