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.

[Herfried K. Wagner [MVP]]

Re: A VB.NET Critique

* ericmuttta@emai l.com (Eric) scripsit:[color=blue]
> 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.[/color]

<http://www.vb7-critique.741.co m/VB7_Semantics_C ritique.htm>:

I don't understand what's bad to allow to call a procedure recursively.
The "problem" applies to every function the "user" of the programming
language can write. Leaving "that out" is IMO a useless exception.

<http://www.vb7-critique.741.co m/VB7_OOP_Critiqu e.htm>:

As I am not a native English-speaker, I don't have any problem to
understand the meaning of 'MustInherit'. If I use a programming
language, I read its syntax definition first and then have a look at the
code.

<http://www.vb7-critique.741.co m/VB7_Type_System _Critique.htm>:

Array bases: Yes, I agree, that's a problem. But it's not a problem of
VB.NET. There was a lot of discussion in the early beta phase of
..NET/VB.NET. I never liked 0-based arrays. I would prefer arrays like
in VB6. The same for the declaration of arrays (specifying of the upper
bound and not the number of elements). This problem can be solved by
changing the default start index of arrays to 1.

Field Initializers: ACK. That's an ugly limitation.

<http://www.vb7-critique.741.co m/VB7_Syntax_Crit ique.htm>:

This code would be IMO really ugly because of the assignment to a
variable which doesn't seem to have a type:

\\\
Dim c = 1, d = 2, e As Integer = 3
///

I'll go to bed now...

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[David]

Re: A VB.NET Critique

I should really trim the group list, but your PS made me unsure about
it.

On 2004-01-04, Eric <ericmuttta@ema il.com> wrote:[color=blue]
> 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.[/color]

OK, a few thoughts, starting with the Syntax section.

The long rant about multiple initializations makes some sense, but I
personally find all of your alternatives to be much worse and much less
readable. Putting the type after the varname in declarations makes a
lot of usable syntax impossible, but that's just complaining about Basic
being Basic.

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.

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.
[color=blue]
>You cannot declare an optional parameter which is of a structure type.[/color]
[color=blue]
> Public Sub Foo(Optional Arg As SomeStructure = Nothing)[/color]
[color=blue]
> 'this wont compile
> Why the limitation, when the above makes perfect sense?[/color]

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

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. 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. And the idea that
zero-based arrays are more error prone is little more than personal
opinion, and one that flys in the face of an awful lot of comp sci
literature.

I think you have some decent points to make, but it seems like half of
the essay stems from a total misunderstandin g of .NET types and an
insistence on working with Option Strict Off. I agree with some of your
points, structure semantics are a mess, array declarations are error
prone, but unfortunately I also think that the good points are buried in
a morass of long rants that either exhibit misunderstandin g of the
language or are simply nit-picking at silly thing (e.g, the
"MustInheri t" example, the disgruntled employee with bad variables names
(would names like 'AAAAAAA' be any more readable?)).

All in all, I think the essay would be much more useful if you could
separate the "this is a problematic construction and here's why" issues
from the "I would have done it this way" issues.

Hey, you asked for comments...

--
David
dfoster at
hotpop dot com

[Cor]

Re: A VB.NET Critique

Hi Eric,

It looks very much written from a personal view.

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.

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.

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

Just my thoughts

Cor

[Eric]

Re: A VB.NET Critique

Thank you all for taking some time to read the critique and sharing
your thoughts. I have been working full time trying to keep up with
the responses in this group:

http://tinyurl.com/2jszd

and will make some time tomorrow to respond more fully to the
responses here on Google groups.

Thanks again,
Eric.

Ps: David I think it's safe if you want to trim the group list now. I
think the regulars of comp.programmin g who would take interest in the
critique have already seen the post.

ericmuttta@emai l.com (Eric) wrote in message news:<ca5584cb. 0401041559.538b f033@posting.go ogle.com>...[color=blue]
> 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.[/color]

[Programmer Dude]

Re: A VB.NET Critique

David wrote:
[color=blue]
> I think you have some decent points to make, but it seems like half
> of the essay stems from a total misunderstandin g of .NET types and
> an insistence on working with Option Strict Off. I agree with some
> of your points, [...], but unfortunately I also think that the good
> points are buried in a morass of long rants that either exhibit
> misunderstandin g of the language or are simply nit-picking at silly
> thing...[/color]

I will second that opinion. It's almost exactly what I thought as
I was reading it.

--
|_ CJSonnack <Chris@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|

[Eric]

Re: A VB.NET Critique

hirf-spam-me-here@gmx.at (Herfried K. Wagner [MVP]) wrote in message news:<OZYOYEz0D HA.1668@TK2MSFT NGP10.phx.gbl>. ..
[color=blue]
> <http://www.vb7-critique.741.co m/VB7_Semantics_C ritique.htm>:
>
> I don't understand what's bad to allow to call a procedure recursively.
> The "problem" applies to every function the "user" of the programming
> language can write. Leaving "that out" is IMO a useless exception.[/color]

You are right about allowing recursive procedure calls. I'm not
against recursion in general (its an essential algorithmic tool), I
just feel that allowing recursion on Main() is both unnecessary and
dangerous due to the problems it can create. The semantic value of
Main() makes it special and different to all other procedures.
Consider for instance, to make recursion on Main() work like recursion
on any other procedure, Main() would need to allow parameters (which
it doesnt) and the user would need to be able to directly invoke all
the initialisation steps that take place before the run-time calls
Main() during program start-up. Again, that is something the user
can't do.

Opinions will differ, but my view is that since this feature (allowing
Main() to be called by the user) has little or no application and in
fact creates problems in some cases, it should be taken it out. I
admit its not a major issue, but like that nail that you dont see
round the corner until you step on it, leaving it in is IMO not such a
good idea.

[color=blue]
> <http://www.vb7-critique.741.co m/VB7_OOP_Critiqu e.htm>:
>
> As I am not a native English-speaker, I don't have any problem to
> understand the meaning of 'MustInherit'. If I use a programming
> language, I read its syntax definition first and then have a look at the
> code.[/color]

That is commendable indeed and is really the only way to get the
complete picture (or part of the complete picture) of a language. I
too am not a native English-speaker and when I first encountered
'MustInherit' the reason for the choice of words was immediately
apparent and I asked no further questions. One thing to note however
is that we are both *experienced* developers and we both probably had
a taste of all of OOP in languages other than VB (e.g Java or C++).
Experienced developers, by definition, will have more knowledge about
things and will ask less questions. But from a language design point
of view, one also needs to consider experienced programmers who've
never done OOP before and beginner-level programmers (especially since
VB has a reputation of attracting complete biginners). What may be
obvious to the experienced developers may not be obvious to the
beginning developers. The questions I say may be asked about
MustInherit, are imagined to be those that would be asked by a person
completely new to OOP and or programming. If one previously knows
about the rules for abstract classes then MustInherit is crystal
clear, but if one doesn't and questions why this keyword was chosen, I
would imagine that the questions I pose in that section, would also
come to their mind.
[color=blue]
> <http://www.vb7-critique.741.co m/VB7_Type_System _Critique.htm>:
>
> Array bases: Yes, I agree, that's a problem. But it's not a problem of
> VB.NET.[/color]

I understand the implementers wanted to be as close to the .NET CTS as
possible, but wouldnt they have been able to still provide a one-based
view of arrays? Granted, that would cause a slight loss of efficiency
but at the gain of the intuitiveness of one-based arrays which further
helps in the development of correct algorithms. A slower but correct
algorithm is countless times more valuable than a fast but incorrect
algorithm.

VB6 allowed n-based arrays (for all positive and negative integral
values of n, where 0 and 1 were most common) so no matter what choice
was made someone was bound to have their toes stepped upon. But such
is the nature of all design choices and I am glad that MS atleast
standardized on a single base for arrays (the situation in VB6 of
different possible bases for any array was quite problematic).

The 2 most common arguments I've heard for zero-based arrays is
efficiency and the fact that "every other language" does it that way
because its the "nature of computer science". Fair enough, but if
Moore's law continues to hold, the first argument will increasingly
become a non-issue (if it isn't one already) for a good chunk of
programs that VB developers make and as for the second argument, I
believe the creator of Ruby has some good advice:

"Be nice to others. Consider interface first: man-to-man,
man-to-machine, and machine-to-machine. And again remember the human
factor is important."
(http://www.artima.com/intv/craft2.html)
[color=blue]
> There was a lot of discussion in the early beta phase of
> .NET/VB.NET. I never liked 0-based arrays. I would prefer arrays like
> in VB6. The same for the declaration of arrays (specifying of the upper
> bound and not the number of elements). This problem can be solved by
> changing the default start index of arrays to 1.[/color]

After spending a good number of years using patterns that depend on
the base being 1, the new zero-based world of VB.NET makes me stumble
continously. Alas, change is inevitable (though not all change is
necessary) and I along with other people will just have to get used to
it.
[color=blue]
> Field Initializers: ACK. That's an ugly limitation.
>
> <http://www.vb7-critique.741.co m/VB7_Syntax_Crit ique.htm>:
>
> This code would be IMO really ugly because of the assignment to a
> variable which doesn't seem to have a type:
>
> \\\
> Dim c = 1, d = 2, e As Integer = 3
> ///[/color]

Yeah, it does look kinda weird and is a rather unfortunate side-effect
of having the type name appear after the variable name. It was just a
suggestion and I am glad that atleast one person views it as ugly -
that helps add balance to the views which is important if Paul Vick
and his team ever decide to look at the critique.
[color=blue]
> I'll go to bed now...[/color]

Thank you very much for your time Herfried, and for sharing your
views.

Cheers,
Eric :)

[Eric]

Re: A VB.NET Critique

David <dfoster@127.0. 0.1> wrote in message news:<slrnbvho8 j.44s.dfoster@w oofix.local.dom >...
[color=blue]
> OK, a few thoughts,[/color]

Thank you for spending some time to look at the critique.
[color=blue]
> starting with the Syntax section.[/color]

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.
[color=blue]
>
> The long rant about multiple initializations makes some sense[/color]

Yes, that section will need to be rewritten to be more concise. Others
have had the same impression and after re-reading it myself, I get the
same view.
[color=blue]
> but I personally find all of your alternatives to be much worse and much less
> readable.[/color]

Fair enough, some others have thought the same thing too. IIRC, I
think I came up with that proposal like this. I had initially given
the declarations like so:

Dim c, d, e As Integer

then later on realised that I wanted to initialise all three variables
at their point of declaration, so I assumed one could just do this:

Dim c = 1, d = 2, e As Integer = 3

but obviously the compiler didn't agree with me. It does look awkward,
because as you mention below, the type name coming after the variable
name makes a lot of usable syntax impossible.
[color=blue]
> Putting the type after the varname in declarations makes a
> lot of usable syntax impossible, but that's just complaining about Basic
> being Basic.[/color]

I know what you mean :). 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

and afterall, a certain degree of verbosity is, IMO, what makes VB
easier to understand so its no biggie.
[color=blue]
> 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.[/color]

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>
[color=blue]
> 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.[/color]

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

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.
[color=blue][color=green]
> >You cannot declare an optional parameter which is of a structure type.[/color]
>[color=green]
> > Public Sub Foo(Optional Arg As SomeStructure = Nothing)[/color]
>[color=green]
> > 'this wont compile
> > Why the limitation, when the above makes perfect sense?[/color]
>
> Because the above doesn't make perfect sense, in fact it makes
> absolutely no sense at all.[/color]

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

that syntax restriction on optional structure arguments still seems to
be an arbitrary limitation to me. Part of the problem stems from the
fact that VB.NET requires you to explicitly provide a default value
for optional parameters - a requirement which is somewhat redundant
since VB states that variables will always be automatically
initialised to the default value of their type. Maybe there is a good
reason for the limitation and if someone can point it out to me, I
will stand corrected.
[color=blue]
> 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.[/color]

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

*Array.Length
Gets a 32-bit integer that represents the total number of elements in
all the dimensions of the System.Array.

*ICollection.Co unt
When implemented by a class, gets the number of elements contained in
the System.Collecti ons.ICollection .

The big give-away being the substring "number of elements" appearing
in *both* definitions.
[color=blue]
> 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.[/color]

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

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. This is especially so
if you are not using dynamic arrays but I guess it isnt simply because
VB doesnt allow you to declare fixed size arrays. Actually that last
sentence may not be entirely true, because I came across an attribute
called VBFixedArrayAtt ribute that may allow declaration of fixed size
arrays but I will need to look into it.
[color=blue]
> And the idea that
> zero-based arrays are more error prone is little more than personal
> opinion, and one that flys in the face of an awful lot of comp sci
> literature.[/color]

See my initial response to Herfried about this one.
[color=blue]
> I think you have some decent points to make,[/color]

Thank you :)
[color=blue]
> but it seems like half of
> the essay stems from a total misunderstandin g of .NET types[/color]

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. I am always open to
correction, but I have attempted to provide the basis for my reasoning
(see earlier on in this response, where I quote myself from another
group) and hopefully someone can see where I am coming from with
respect to some of my arguments about the type system.
[color=blue]
> and an insistence on working with Option Strict Off.[/color]

Actually, I write all my production code with Option Strict On. I
don't quite remember if Option Strict was On in every instance where I
wrote the snippets, but I will confirm that in the next revision of
the critique.
[color=blue]
> I agree with some of your
> points, structure semantics are a mess, array declarations are error
> prone, but unfortunately I also think that the good points are buried in
> a morass of long rants[/color]

Yeah, I will need to revise some parts to remove the unnecessary "blah
blah" and make the points more concise.
[color=blue]
> are simply nit-picking at silly thing (e.g, the
> "MustInheri t" example, the disgruntled employee with bad variables names
> (would names like 'AAAAAAA' be any more readable?)).[/color]

See my initial response to Herfried, for my reasoning on the
'MustInherit' example. As for the variable names consisting purely of
underscores and the disgruntled employee, the basis for my argument is
similar to that for a recursive Main(): IMO, unnecessary flexibility
is just as bad as no flexibility.
[color=blue]
> All in all, I think the essay would be much more useful if you could
> separate the "this is a problematic construction and here's why" issues
> from the "I would have done it this way" issues.[/color]

I am currently investigating a different format for the next
revision, so as to make the essay more useful. Many thanks for that
suggestion.
[color=blue]
> Hey, you asked for comments...[/color]

And great comments I got :). Thanks for sharing yours.

Cheers,
Eric :)

[Programmer Dude]

Re: A VB.NET Critique

Just a couple random thoughts....


Eric wrote:
[color=blue]
> 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[/color]

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.

[color=blue]
> Everything in .NET (and hence VB7) *is* an object because all
> types either directly or indirectly inherit from Object.[/color]

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?

C# does seem to have some "gotchas" with regard to the semantics
of native vs: object types.

[color=blue]
> 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.[/color]

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.


Regarding:
[color=blue]
> *Array.Length
> ...
> *ICollection.Co unt[/color]

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.


--
|_ CJSonnack <Chris@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|

[Daniel O'Connell]

Re: A VB.NET Critique


"Programmer Dude" <Chris@Sonnack. com> wrote in message
news:3FFDB3A3.D CB5F1BA@Sonnack .com...[color=blue]
> Just a couple random thoughts....
>
>
> Eric wrote:
>[color=green]
> > 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[/color]
>
> 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.
>
>[color=green]
> > Everything in .NET (and hence VB7) *is* an object because all
> > types either directly or indirectly inherit from Object.[/color]
>
> 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?[/color]
Not quite, C# natives(int, uint, char, etc) are aliases to the System
equivilents(Sys tem.Int32, System.UInt32, System.Char respectivly). Each of
these values are value types which are *NOT* reference types with value
semantics, they are value types. In the case of
Dim x as Integer
You get a value on the stack that exists at a specific offset, not a
reference to an object. No reference to x will likely ever exist(not sure
what happens in the case of ref parameters with value types, though it may
be a copy back), to get a reference to an object with the value of x(not x
itself, note) requires you to assign it to a variable of type object(in
VB.NET or C# anyway, C++ requires the use of the __box keyword). Boxing
creates an object on the heap and returns a reference to it, this allows
value types to be passed into parameters typed as Object and to be treated
as reference type when needed, but to be value types in most other cases

Dim x As Integer
Dim o as Object
Dim y as Object
o = x ' o is a reference type, refering to the object containing the boxed
value of x
y = x ' y is a reference type, refering to the object containing the boxed
value of x
o is y ' I would still expect this to return false, they should be different
references.

o = x ' o is a reference, refering to the object containing the boxed value
of x
y = o ' y is a reference, containing the same reference as x
o is y ' this should return true

[color=blue]
>
> C# does seem to have some "gotchas" with regard to the semantics
> of native vs: object types.[/color]
There should be none that don't exist elsewhere in the framework. VB may
make it a bit easier but the same issues are there.[color=blue]
>
>[color=green]
> > 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.[/color]
>
> 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.[/color]
It has its values, in languages like C# you can't always be sure what you
are comparing with ==, object == object results in a reference compare,
string == string a value comparison, in most cases it doesn't matter, but
you have to be aware of that possibility. Certain static and instance
methods are used to perform explicit comparisons.[color=blue]
>
>
> Regarding:
>[color=green]
> > *Array.Length
> > ...
> > *ICollection.Co unt[/color]
>
> 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.
>
>
> --
> |_ CJSonnack <Chris@Sonnack. com> _____________| How's my programming? |
> |_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
> |______________ _______________ _______________ _|_____________ __________|[/color]

[Cor]

Re: A VB.NET Critique

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

Re: A VB.NET Critique

Eric <ericmuttta@ema il.com> wrote:[color=blue]
> 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*.[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: A VB.NET Critique

Eric <ericmuttta@ema il.com> wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> My complaint is geared towards some of the
> types being half way between the value-type and reference-type
> categories[/color]

Arrays are reference types in all respects - how are they "half way" to
being value types?
[color=blue]
> 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."[/color]

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.
[color=blue]
> 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.[/color]

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).
[color=blue][color=green]
> > but it seems like half of
> > the essay stems from a total misunderstandin g of .NET types[/color]
>
> 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.[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Edward G. Nilges]

Re: A VB.NET Critique

Programmer Dude <Chris@Sonnack. com> wrote in message news:<3FFDB3A3. DCB5F1BA@Sonnac k.com>...[color=blue]
> Just a couple random thoughts....
>
>
> Eric wrote:[/color]

Very interesting ontopic and intelligent critique, Eric. Thank you.[color=blue]
>[color=green]
> > 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[/color]
>
> 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.[/color]

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
[color=blue]
>[/color]
[color=blue]
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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]

Re: A VB.NET Critique

On 2004-01-08, Eric <ericmuttta@ema il.com> wrote:[color=blue]
> David <dfoster@127.0. 0.1> wrote in message news:<slrnbvho8 j.44s.dfoster@w oofix.local.dom >...
>[/color]

Focusing on the differences, natch...
[color=blue][color=green]
>> starting with the Syntax section.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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*.[/color]

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.
[color=blue]
> 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[/color]

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,
[color=blue]
>IMO, unnecessary flexibility
> is just as bad as no flexibility.
>[color=green]
>> 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.[/color]
>
>:) 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).[/color]

I doubt that's the difference. I started with C, then C++ when I
started programming.
[color=blue]
>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."[/color]

Actually, named arguments aren't really necessary in the example (I
realize you had another example which used them).
[color=blue]
> 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.[/color]

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).
[color=blue][color=green][color=darkred]
>> >You cannot declare an optional parameter which is of a structure type.[/color]
>>[color=darkred]
>> > Public Sub Foo(Optional Arg As SomeStructure = Nothing)[/color]
>>[color=darkred]
>> > 'this wont compile
>> > Why the limitation, when the above makes perfect sense?[/color]
>>
>> Because the above doesn't make perfect sense, in fact it makes
>> absolutely no sense at all.[/color]
>
> 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."[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> They have different meanings? Thats not the impression I get when I
> read the documentation of those respective properties:[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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