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.programming, this may be off topic, but I've
posted there because the critique was part of a discussion in that
group. 37  2048 
I should really trim the group list, but your PS made me unsure about
it.
On 2004-01-04, Eric <er********@email.com> wrote: 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.
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.
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.
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 misunderstanding 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 misunderstanding of the
language or are simply nit-picking at silly thing (e.g, the
"MustInherit" 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
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
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.programming who would take interest in the
critique have already seen the post. er********@email.com (Eric) wrote in message news:<ca**************************@posting.google. com>... 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.programming, this may be off topic, but I've
posted there because the critique was part of a discussion in that
group.
David wrote: I think you have some decent points to make, but it seems like half
of the essay stems from a total misunderstanding 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
misunderstanding of the language or are simply nit-picking at silly
thing...
I will second that opinion. It's almost exactly what I thought as
I was reading it.
--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
David <df*****@127.0.0.1> wrote in message news:<sl********************@woofix.local.dom>... OK, a few thoughts,
Thank you for spending some time to look at the critique.
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.
The long rant about multiple initializations makes some sense
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.
but I personally find all of your alternatives to be much worse and much less
readable.
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.
Putting the type after the varname in declarations makes a
lot of usable syntax impossible, but that's just complaining about Basic
being Basic.
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.
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*. 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>
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). 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.
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."
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.
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:
*Array.Length
Gets a 32-bit integer that represents the total number of elements in
all the dimensions of the System.Array.
*ICollection.Count
When implemented by a class, gets the number of elements contained in
the System.Collections.ICollection.
The big give-away being the substring "number of elements" appearing
in *both* definitions.
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. 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 NullReferenceException. 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 VBFixedArrayAttribute that may allow declaration of fixed size
arrays but I will need to look into it.
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.
See my initial response to Herfried about this one.
I think you have some decent points to make,
Thank you :)
but it seems like half of
the essay stems from a total misunderstanding 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. 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.
and an insistence on working with Option Strict Off.
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.
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
Yeah, I will need to revise some parts to remove the unnecessary "blah
blah" and make the points more concise.
are simply nit-picking at silly thing (e.g, the
"MustInherit" example, the disgruntled employee with bad variables names
(would names like 'AAAAAAA' be any more readable?)).
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.
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.
I am currently investigating a different format for the next
revision, so as to make the essay more useful. Many thanks for that
suggestion.
Hey, you asked for comments...
And great comments I got :). Thanks for sharing yours.
Cheers,
Eric :)
Just a couple random thoughts....
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.
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?
C# does seem to have some "gotchas" with regard to the semantics
of native vs: object types.
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.
Regarding:
*Array.Length
...
*ICollection.Count
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 <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
"Programmer Dude" <Ch***@Sonnack.com> wrote in message
news:3F***************@Sonnack.com... Just a couple random thoughts....
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.
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?
Not quite, C# natives(int, uint, char, etc) are aliases to the System
equivilents(System.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
C# does seem to have some "gotchas" with regard to the semantics
of native vs: object types.
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.
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.
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.
Regarding:
*Array.Length
...
*ICollection.Count
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 <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
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
Eric <er********@email.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.ValueType 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.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Eric <er********@email.com> wrote: 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.
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 NullReferenceException. 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
NullReferenceExceptions 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 misunderstanding 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.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Programmer Dude <Ch***@Sonnack.com> wrote in message news:<3F***************@Sonnack.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.
On 2004-01-08, Eric <er********@email.com> wrote: David <df*****@127.0.0.1> wrote in message news:<sl********************@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
Edward G. Nilges <sp*********@yahoo.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.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Cor" <no*@non.com> wrote in message news:<u2**************@TK2MSFTNGP10.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.Globalization.CultureInfo
cul = System.Globalization.CultureInfo.CurrentCulture
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.
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP***********************@msnews.microsoft.c om>... Edward G. Nilges <sp*********@yahoo.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.
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP***********************@msnews.microsoft.c om>... Eric <er********@email.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.ValueType 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>
Programmer Dude <Ch***@Sonnack.com> wrote in message news:<3F***************@Sonnack.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.ValueType.
3. System.ValueType 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.Count
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 :) sp*********@yahoo.com (Edward G. Nilges) wrote in message news:<f5**************************@posting.google. com>... Programmer Dude <Ch***@Sonnack.com> wrote in message news:<3F***************@Sonnack.com>... Just a couple random thoughts....
Eric wrote:
Very interesting ontopic and intelligent critique, Eric. Thank you.
Thank you Edward, for that vote of confidence :)
<snip>
I'm a big proponent of:
Dim c As Integer = 1 ' .....
Dim d As Integer = 2 ' .....
Dim e As Integer = 3 ' .....
Because it helps you to add documentation as to the purpose
of your variables. I also think it's easier to read and gives
you a better picture of how many locals you have.
I agree. One line per variable. If it is at all screwy as in the case
of a collection that is restricted to a type, add a comment:
Dim colCustomer As Collection ' Of type objCustomer
Actually, there is a now a way to enforce that assertion and ensure
that only objects of type objCustomer will go into that collection.
You create a wrapper around the Collection class, and do the checking
using the reflection facilities, every time an item is added to the
collection. This helps a little, but you still need to cast when
retrieving items from the collection. Later this year, all that will
be history because generics are coming to VB.NET :)
By way of logical deduction, the Is operator should work in all
cases because it works on object types and every type in
.NET is an object. The problem? It doesn't.
I don't agree it should. The sematics of the Is operator, AIUI,
is to compare, essentially, the "pointers". The semantics of
a non-object type are such it doesn't HAVE a "pointer".
I think it is well to make distinct the semantics of "equal VALUE"
and "equal references". Just MO.
Absolutely. While everything is an object, there is an important
distinction that would be hidden by allowing IS to take value types.
Furthermore, allowing Is to be applied to value types would provide a
useless facility for it would always have to return False. Each
instance of a Value type, even if it has the same value as another
instance, is a different object.
I agree. However since the implementers are already cheating about the
actual implementation of value types the same could be easily done for
the Is operator. I am not necessarily proposing that it be done, but
it would help consistency if it was. To the everyday programmer this
lack of consistency is a non-issue (and may be favourable as some
people's views indicate) but to the language designer, its food for
thought.
"Identity of indiscernables?" Give me a break. In terms of Leibniz'
metaphysics, two distinct variables have two different space time
coordinates by definition, unless the language allows aliasing as seen
in the outdated and unsafe language C. Yes we have AddressOf but for
specific reasons in specific contexts.
I'll have to read more on Leibniz's work, it sounds interesting.
Finally we get to the case of Nothing. Is Nothing, Nothing? By this
time the compiler writer has taken either to strong drink or
Heidegger.
LOL. The output of the following snippet seems to be in agreement:
If Nothing Is Nothing Then
MsgBox("The compiler writer took a stong drink.")
End If
Cheers,
Eric :)
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP***********************@msnews.microsoft.c om>... Edward G. Nilges <sp*********@yahoo.com> wrote:
<snip>
Absolutely. While everything is an object, there is an important
distinction that would be hidden by allowing IS to take value types.
<snip>
Actually, *not* everything is an object. Everything can be *converted*
to an object via boxing, but a value type value itself is *not* an
object.
Implementation wise, yes, but conceptually, no. See response to Programmer Dude.
Cheers,
Eric :)
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP***********************@msnews.microsoft.c om>... Eric <er********@email.com> wrote: This is going to be an interesting problem area of the .NET CTS
resulting from the difficult (and in some ways, pointless) goal of
type unification. Everything in .NET (and hence VB7) *is* an object
because all types either directly or indirectly inherit from Object.
If you agree with me so far, then you will also agree that *all* types
in .NET are actually *reference* types its just that *some* of those
reference types (those that inherit from ValueType) have *value
semantics*.
No, *not* everything in .NET is an object. Not everything in .NET is a
reference type.
I can see where you're coming from, but you're wrong. I believe section
8.2.4 of the ECMA spec is the relevant bit:
<snip long quote from ECMA spec>
The important bit of 8.9.7 is:
<quote>
Value types do not support interface contracts, but their associated
boxed types do.
A value type does not inherit; rather the base type specified in the
class definition defines the base type of the boxed type.
</quote>
A look a the class hierarchy via the object browser in VS.NET,
apparently shows that System.ValueType inherits from System.Object.
Cheers,
Eric :)
Edward G. Nilges <sp*********@yahoo.com> wrote: I can see where you're coming from, but you're wrong. I believe section
8.2.4 of the ECMA spec is the relevant bit:
OK, this denies that the value is an object from the standpoint of the
spec. And I agree that you cannot inherit a value type.
Nonetheless, value types Inherit from object.
No, the *boxed* types inherit from object (via ValueType). This *is* an
important distinction.
I think there's a real danger here of a Scholastic and pointless
discussion of what is and is not an object. I'd point out that C
experts CLAIM that their values are objects.
I'd say the hell with it. Who cares. Use the value right and vaya con
dios.
But you are saying that to be an object the type must have a reference
type. Doesn't this mean that it's wrong to speak of value objects? OK,
but then why do values have properties and methods?
I'll agree that it's difficult in terms of terminology, but I think
it's worth being clear on it where possible. The value "5" for instance
(as a bit pattern), has no actual type, even if you know the length -
if it's a 32 bit "5" it could be an int32, a uint32 or a single, as the
says. The value itself is not an object - but methods can be called on
the boxed type which act on a value *as if* the value is an object.
I think an overly Scholastic reading would make for poor pedagogy.
Whereas I think that an overly "loose" reading where everything's a
reference type when it clearly isn't makes for poor understanding and
communication.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Eric <er********@email.com> wrote: Actually, *not* everything is an object. Everything can be *converted*
to an object via boxing, but a value type value itself is *not* an
object.
Implementation wise, yes, but conceptually, no. See response to Programmer Dude.
No, conceptually not everything is an object either. Please read the
quotes from the spec *very carefully* - preferrably reading them in the
context of the rest of the spec as well.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Eric <er********@email.com> wrote: The important bit of 8.9.7 is:
<quote>
Value types do not support interface contracts, but their associated
boxed types do.
A value type does not inherit; rather the base type specified in the
class definition defines the base type of the boxed type.
</quote>
A look a the class hierarchy via the object browser in VS.NET,
apparently shows that System.ValueType inherits from System.Object.
Please read the quote again, carefully. The type System.Int32, for
instance, isn't the actual type of an integer - it's the *boxed* type
of an integer.
Can you not see how what you're saying is going against what the spec
says?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>... Eric <er********@email.com> wrote: 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.
It makes perfect sense. The first one has defined a variable of type
"reference to array of integers", and has implicitly set the value to
nothing.
The second one has defined a variable of type "reference to array of
integers", and has explicitly set the value to be a reference to an
empty array.
The reason I personally think its not logical...hmm, actually it is
logical, its just not friendly so to speak. Simply defining the
default value of an array to be a zero length array, such that:
Dim arr1() As Integer
is synonymous with:
Dim arr1() As Integer = {}
would, IMO, be more practical.
My complaint is geared towards some of the
types being half way between the value-type and reference-type
categories
Arrays are reference types in all respects - how are they "half way" to
being value types?
For instance, you are not required to use the New operator and can do:
Dim arr() As Integer = {1, 2, 3}
instead of:
Dim arr() As Integer = New Integer() {1, 2, 3}
This absence of New in the first syntax gives no indication that
arrays are indeed reference types and are allocated on the heap. It
makes it appear as if arrays are stack allocated and are hence value
types. A similar thing can be said about the New operator and
structures.
My reasoning for this is based on my understanding of the semantics of
the New operator both from VB6 and other OOP languages like C++ and
Java, but YMMV.
(Note: that syntactical allowance is done for convenience and I am
glad its allowed. For other syntactical exceptions that have to be
done to make type unification viable, see concepts such as "manifest
classes" in section 3.3 of the Blue language paper at
http://tinyurl.com/yryyz )
which is one of the unfortunate side-effects of the goal
of type unification. The basis for my complaint about the Length
property is given in the "Arrays as objects" section:
"I now have to worry about null references while am using arrays. For
instance, the Length property should logically contain zero when an
array has no elements. However, because a reference to an array
without elements is a null reference, I can't check the Length of an
uninitialised array without getting a NullReferenceException. If
arrays were not objects or the compiler was kind enough to 'cheat' and
return 0 for the expressions like "MyArray.Length" when MyArray was
null, I could retrieve certain info (array length, number of
dimensions and upper bounds of each dimension) without ever worrying
about null references."
Yes, but if arrays weren't objects there's be any number of other
problems with them. Passing them around would be a nightmare, for
instance - you'd have to pass them by reference all over the place just
for the sake of performance. Yuk.
I agree but there is a way to implement them to satisfy both the
performance criteria and the avoidance of NullReferenceException.
There are two parts to an array. The descriptor, which contains type
information on the array (number of dimensions, size of each
dimension, pointer to data, etc) and the actual array data. If you
allocate the descriptor on the stack and the data on the heap the
problem vanishes. One can check the array type info without getting
exceptions because the descriptor is stack allocated, and passing them
around can be defined as copying the descriptor rather than the data
hence removing the performance penalty.
Furthermore, since ReDim can't change the number of dimensions for an
array in VB.NET, the above proposal of stack allocating the descriptor
works well. In VB6, the descriptor would need to be allocated on the
heap (due to ReDim's behaviour) otherwise the compiler writer will
need some serious black magic to implement dynamic allocation within
the current procedure's stack frame.
Properties such as the number of dimensions, the upper bound of each
dimension and the length of an array should be things that you can
find out whether the array has elements or not.
Unless there is an array, there *is* no upper bound though - and an
array always has all its possible elements, even if some of them are
null/nothing. In your previous example, arr1.Length wasn't saying "what
is the length of the array which is arr1's value", it's saying "what is
the length of the array which arr1's value refers to" - and given that
arr1's value *doesn't* refer to an array, it's natural that there
should be an exception.
Natural? Yes. Convenient and efficient? Not IMO. (See previous
comments in this same post).
It's important to distinguish between the idea of the value of a
variable being an actual array (which it isn't) and it being either a
reference to an array, or nothing.
Agreed. One thing though: it can be quite convenient if the variable
is the actual array (i.e the array descriptor and data are stack
allocated) and the performance gains for small, fixed-size arrays
(such as the 3x3 transformation matrices used in graphics programming)
can be very substantial.
You shouldn't usually be really *worrying* about
NullReferenceExceptions though - either null is a valid value for the
variable at that point in time, in which case it may well have a
special meaning as distinct from an empty array, or it may not be
valid, in which case throwing an exception is perfectly reasonable
(although you may wish to make the check at the start of the method if
it's coming in as a parameter, for instance).
You are right that I shouldn't have to be worrying about
NullReferenceExceptions but with the current implementation, I have
no choice but to worry. Even if I do check incoming parameters,
VB.NET doesn't allow declarations of fixed-size arrays and I can wipe
out the array at any time and later get into trouble:
Sub Bar(ByVal arr() As Integer)
If arr Is Nothing Then
'take appropriate action
End If
'some code here
Erase arr
'some more code here
For n As Integer = 0 To arr.Length - 1
'blah
Next
End Sub
The For loop fails with a NullReferenceException because of using the
Length property on a null object. To avoid that, I either have to
ensure that an array is never wiped out (an endeavour that will fail
atleast once) or litter my code with "If" statements to check for the
possibility each time I want to access an instance member of the Array
class. but it seems like half of
the essay stems from a total misunderstanding of .NET types
I am human and hence prone to being wrong, but I can confidently say
(without meaning to sound haughty) that I have a fairly good if not
firm understanding of the .NET type system.
Given the above (and my previous post), I'm afraid I have to disagree
with you. The suggestion that all types are reference types is the
biggest problem, IMO.
I should have been clearer initially, about the conceptual and
implementation aspects when giving my explanation. My bad.
Cheers,
Eric :)
Eric <er********@email.com> wrote: That is what I believe Daniel is getting at in his response when he
says native types are not objects. From an implementation point of
view, he is correct and native types (or "value types" in .NET
parlance) are not reference types and dont behave like objects. But
*conceptually*, if you apply the definition of inheritance in OOP an
Integer for instance, is a reference type:
<snip>
If my logic can be proved unsound, then I will stand corrected.
Your logic is unsound because although the *boxed* type for Integer
does indeed inherit from object, the value type itself doesn't, and
can't. As the specification says, value types themselves *do not*
inherit - only their boxed types do.
Now, whether "System.Int32" (Integer) is the boxed type or the value
type itself seems a bit confused, and seems to depend on context. This,
I'll readily agree, is a pain when trying to be precise about these
things.
The specification states that the class definition is used to define
both of them.
The specification *is* very clear, however, that not everything is an
object type, or a reference type. It even says explicitly "Value types
are not object types".
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Eric <er********@email.com> wrote: It makes perfect sense. The first one has defined a variable of type
"reference to array of integers", and has implicitly set the value to
nothing.
The second one has defined a variable of type "reference to array of
integers", and has explicitly set the value to be a reference to an
empty array.
The reason I personally think its not logical...hmm, actually it is
logical, its just not friendly so to speak. Simply defining the
default value of an array to be a zero length array, such that:
Dim arr1() As Integer
is synonymous with:
Dim arr1() As Integer = {}
would, IMO, be more practical.
What would
Dim arr1() As Integer = Nothing
do then? If it would create a variable with an initial null reference
value, then you still haven't bought much as array type expressions can
still be null and you can still get NullReferenceExceptions. Indeed,
you'll have that problem anyway as other languages *do* allow array
type expressions to be null.
When is it actually practical to use an array type variable without
assigning a reasonable value to it anyway? I would argue that actually
using the value of arr1 when it's only been declared as
Dim arr1() As Integer
and hasn't had an explicit value assigned to it yet is almost always
going to be incorrect program logic anyway.
Arrays are reference types in all respects - how are they "half way" to
being value types?
For instance, you are not required to use the New operator and can do:
Dim arr() As Integer = {1, 2, 3}
instead of:
Dim arr() As Integer = New Integer() {1, 2, 3}
This absence of New in the first syntax gives no indication that
arrays are indeed reference types and are allocated on the heap. It
makes it appear as if arrays are stack allocated and are hence value
types. A similar thing can be said about the New operator and
structures.
Ah, right. Yes, the language here is hiding the fact that it's a
reference type to some extent - but it still *is* a reference type,
entirely.
My reasoning for this is based on my understanding of the semantics of
the New operator both from VB6 and other OOP languages like C++ and
Java, but YMMV.
Array types are reference types in Java as well, but the following is
perfectly legal:
public class Test
{
public static void main(String[] args)
{
String[] test = {"hello", "there"};
for (int i=0; i < test.length; i++)
{
System.out.println (test[i]);
}
}
}
Again, no new but the array itself is on the heap. It's just a common
syntactical allowance.
(Note: that syntactical allowance is done for convenience and I am
glad its allowed. For other syntactical exceptions that have to be
done to make type unification viable, see concepts such as "manifest
classes" in section 3.3 of the Blue language paper at
http://tinyurl.com/yryyz )
Right - but it *is* only a syntactical allowance, and doesn't in any
way show the type system *itself* to have "half-way" types.
Yes, but if arrays weren't objects there's be any number of other
problems with them. Passing them around would be a nightmare, for
instance - you'd have to pass them by reference all over the place just
for the sake of performance. Yuk.
I agree but there is a way to implement them to satisfy both the
performance criteria and the avoidance of NullReferenceException.
There are two parts to an array. The descriptor, which contains type
information on the array (number of dimensions, size of each
dimension, pointer to data, etc) and the actual array data. If you
allocate the descriptor on the stack and the data on the heap the
problem vanishes. One can check the array type info without getting
exceptions because the descriptor is stack allocated, and passing them
around can be defined as copying the descriptor rather than the data
hence removing the performance penalty.
Interesting idea, although I'll need to think about it further before
necessarily agreeing it would be a *good* idea. Of course, you could
implement that yourself quite easily as a value type which contained an
array. Until generics come in, you'll have to create a different type
for each array type you want, of course.
I'll think about that some more. I *think* I actually rather like being
able to tell the difference between a 0-length array and a null
reference though.
Also, if array types were value types, people would expect them to
*act* like value types, so you could pass them with impunity and not
have the values inside them change. That wouldn't be true with your
system. Value types which contain mutable reference types always seem a
bad idea to me, just in terms of having misleading semantics. I guess
we could get used to it for arrays in the same way we have with the
different syntax for constructing them.
Properties such as the number of dimensions, the upper bound of each
dimension and the length of an array should be things that you can
find out whether the array has elements or not.
Unless there is an array, there *is* no upper bound though - and an
array always has all its possible elements, even if some of them are
null/nothing. In your previous example, arr1.Length wasn't saying "what
is the length of the array which is arr1's value", it's saying "what is
the length of the array which arr1's value refers to" - and given that
arr1's value *doesn't* refer to an array, it's natural that there
should be an exception.
Natural? Yes. Convenient and efficient? Not IMO. (See previous
comments in this same post).
It's reasonably efficient, I believe, and it *does* have the
convenience of allowing you to distinguish between null and an empty
array.
It's important to distinguish between the idea of the value of a
variable being an actual array (which it isn't) and it being either a
reference to an array, or nothing.
Agreed. One thing though: it can be quite convenient if the variable
is the actual array (i.e the array descriptor and data are stack
allocated) and the performance gains for small, fixed-size arrays
(such as the 3x3 transformation matrices used in graphics programming)
can be very substantial.
But then you have horrendous problems with large arrays. I think all in
all I'm much happier with them being reference types.
You shouldn't usually be really *worrying* about
NullReferenceExceptions though - either null is a valid value for the
variable at that point in time, in which case it may well have a
special meaning as distinct from an empty array, or it may not be
valid, in which case throwing an exception is perfectly reasonable
(although you may wish to make the check at the start of the method if
it's coming in as a parameter, for instance).
You are right that I shouldn't have to be worrying about
NullReferenceExceptions but with the current implementation, I have
no choice but to worry. Even if I do check incoming parameters,
VB.NET doesn't allow declarations of fixed-size arrays and I can wipe
out the array at any time and later get into trouble:
Sub Bar(ByVal arr() As Integer)
If arr Is Nothing Then
'take appropriate action
End If
'some code here
Erase arr
'some more code here
For n As Integer = 0 To arr.Length - 1
'blah
Next
End Sub
The For loop fails with a NullReferenceException because of using the
Length property on a null object.
Absolutely - and you want it to, IMO, as it's showing a bug in your
code.
To avoid that, I either have to
ensure that an array is never wiped out (an endeavour that will fail
atleast once)
So you'll get an exception to show that you've got a bug in your code.
That's what exceptions are for. This is better than the language
masking the fact that you've made a mistake and just silently running
an empty loop effectively.
or litter my code with "If" statements to check for the
possibility each time I want to access an instance member of the Array
class.
No, you don't want to do that unless you know that null/Nothing is a
valid value for the variable at that time. If it is, you need to be
checking it anyway. If it's not, you should get an exception so you can
find out where the problem is. Otherwise it would be like FileStream
not failing if you ask it to open a file which doesn't exist, and
instead returning an empty stream - it masks errors rather than helping
you to fix them. Given the above (and my previous post), I'm afraid I have to disagree
with you. The suggestion that all types are reference types is the
biggest problem, IMO.
I should have been clearer initially, about the conceptual and
implementation aspects when giving my explanation. My bad.
I'm afraid I still think you're wrong - the spec clearly states that
not all types *are* reference types, conceptually as well as in
implementation.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too er********@email.com (Eric) wrote in message news:<ca*************************@posting.google.c om>... David <df*****@127.0.0.1> wrote in message news:<sl********************@woofix.local.dom>...
<snip lotsa stuff>
I will quote myself from another group, to show my reasoning behind
that argument:
<quote start>
This is going to be an interesting problem area of the .NET CTS
resulting from the difficult (and in some ways, pointless) goal of
type unification. Everything in .NET (and hence VB7) *is* an object
because all types either directly or indirectly inherit from Object.
If you agree with me so far, then you will also agree that *all* types
in .NET are actually *reference* types its just that *some* of those
reference types (those that inherit from ValueType) have *value
semantics*. Now then, the Is operator checks if two variables refer to
the same object. By way of logical deduction, the Is operator should
work in all cases because it works on object types and every type in
.NET is an object. The problem? It doesn't. While it is easy to accept
that and just work with it, the issue is still a consistency problem
from a language design point of view and is of more relevance to those
interested in language design. Such exceptions have to be made all the
time when one attempts type unification. Other examples abound in .NET
but to see this in a different language look at this article on the
Blue language (especially section 3.3): http://tinyurl.com/yryyz
<quote end>
Realising the number of languages on .NET and the different wording in
the specs for each of those languages, I would like to reduce the
scope of my statement given above:
"...Everything in .NET (and hence VB7) *is* an object because all
types either directly or indirectly inherit from Object..."
and narrow it down to VB.NET rather than the whole of .NET. It may
still apply to the other languages, but I am not going to gamble on
that by making a potentially wrong all-encompasing statement.
<snip lots more>
Cheers,
Eric :)
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>... Edward G. Nilges <sp*********@yahoo.com> wrote: I can see where you're coming from, but you're wrong. I believe section
8.2.4 of the ECMA spec is the relevant bit:
OK, this denies that the value is an object from the standpoint of the
spec. And I agree that you cannot inherit a value type.
Nonetheless, value types Inherit from object.
No, the *boxed* types inherit from object (via ValueType). This *is* an
important distinction.
OK, I accept it's an important distinction at run time. But my concern
is describing source, where it's meaningful to point out that a value
type can be, notationally an 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'll agree that it's difficult in terms of terminology, but I think
it's worth being clear on it where possible. The value "5" for instance
(as a bit pattern), has no actual type, even if you know the length -
if it's a 32 bit "5" it could be an int32, a uint32 or a single, as the
says. The value itself is not an object - but methods can be called on
the boxed type which act on a value *as if* the value is an object.
You have made an important point. The value is a pure value. I think an overly Scholastic reading would make for poor pedagogy.
Whereas I think that an overly "loose" reading where everything's a
reference type when it clearly isn't makes for poor understanding and
communication.
I agree.
OK, can we agree that virtually a value type is an object?
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP***********************@msnews.microsoft.c om>... Edward G. Nilges <sp*********@yahoo.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.
You are correct. A value *type* (like Integer) is an Object by way of
inheritance, but a value type *value* (like "5") is itself not an
object or if it is, I (like you) wouldn't refer to it as such.
When I quoted myself earlier on in the thread, I used the
all-encompasing word "everything" which would include both values and
types. That didn't quite express what I had in mind, and that was:
every *type* is an object.
I have a bad feeling we might end up having to face the challenge of
coming up with universally-agreed-upon definitions of such terms as
"value", "object", "class" and "type" and more importantly, the
distinctions between those definitions both in natural languages and
in programming languages.
Cheers,
Eric :)
Hi Eric,
What I did show with the date was only meant as an example,
By saying UK time, while I thought the time notation that the UK uses is
used in most parts of the world where arabic figures are used and certainly
in Europe, while the US time notation is more rare, you give something extra
that is not needed for your investigation.
When you just tell about the different notations is enough in my opinion.
That is only an example I used because it was the most simple to show that
on some places you try to prove to much and you come in unsure area's, while
for those who should read your page, it has to be clear.
In my opinion is with your option of giving a date format is nothing wrong,
however exact as you describe the option is clear enough.
An other question, why you have included more newsgroups than VB.net
language, the arguing you had with Jon was already done a short time ago by
OHM, Armin and Jay B., and I thought that at the end of that thread all was
clear.
And I thought that I myself had send a sample to this newsgroup about the IS
and the = operators in this kind of situations.
What I mis in your page is the discussion we had in this newsgroup about
If Not object isNot Nothing
If object Is Nothing
if object Not Is Nothing
If object IsNot Nothing
and the in the eyes from Jay B and me better alternative
Is object Is Something
Is Not object Is Something
Personaly I find that more important than a boxed situation, in which as far
as I could see the VB.net language is consequent (If you want my sample I
can to try to find it, but I post a lot you know and it was in a question I
do not know anymore)
I hope this helps?
Cor
Edward G. Nilges <sp*********@yahoo.com> wrote: No, the *boxed* types inherit from object (via ValueType). This *is* an
important distinction.
OK, I accept it's an important distinction at run time. But my concern
is describing source, where it's meaningful to point out that a value
type can be, notationally an object.
<snip>
OK, can we agree that virtually a value type is an object?
I'm not sure I'd *quite* go with either of those (mostly because I
don't know what *exactly* you mean by "virtually" in the second one).
How about that a value type can be transparently viewed as an object? I
don't think it matters whether or not we agree exactly at this stage
though - we clearly understand the same things, fundamentally.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Eric <er********@email.com> wrote: Actually, *not* everything is an object. Everything can be *converted*
to an object via boxing, but a value type value itself is *not* an
object.
You are correct. A value *type* (like Integer) is an Object by way of
inheritance, but a value type *value* (like "5") is itself not an
object or if it is, I (like you) wouldn't refer to it as such.
Well, all types are themselves objects, and instances of the Type
class, but I don't *think* that's what you're talking about. Whether or
not Integer *derives* from Object (indirectly) depends on which
"Integer" type you're talking about. There's the "boxed type for
Integer" and the "value type for Integer". Both are defined by the same
class definition, and the appropriate type is used at runtime depending
on the situation. For instance, whenever a method is called on a type,
the boxed type is used.
When I quoted myself earlier on in the thread, I used the
all-encompasing word "everything" which would include both values and
types. That didn't quite express what I had in mind, and that was:
every *type* is an object.
I have a bad feeling we might end up having to face the challenge of
coming up with universally-agreed-upon definitions of such terms as
"value", "object", "class" and "type" and more importantly, the
distinctions between those definitions both in natural languages and
in programming languages.
I've been at least *attempting* to use those terms solely according to
the ECMA spec. I would *hope* those definitions also apply to VB.NET,
but I wouldn't like to say for sure.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Eric <er********@email.com> wrote: Realising the number of languages on .NET and the different wording in
the specs for each of those languages, I would like to reduce the
scope of my statement given above:
"...Everything in .NET (and hence VB7) *is* an object because all
types either directly or indirectly inherit from Object..."
and narrow it down to VB.NET rather than the whole of .NET. It may
still apply to the other languages, but I am not going to gamble on
that by making a potentially wrong all-encompasing statement.
I wouldn't like to even say that, myself. I'm pretty sure that VB.NET
also talks about boxing - and the *only* reason that boxing is even
needed is to convert a "pure value" into an object because it isn't one
to start with, surely? However, I'm not particularly bothered by
pushing the point :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Cor wrote:
What I did show with the date was only meant as an example,
By saying UK time, while I thought the time notation that the UK
uses is used in most parts of the world where arabic figures are
used and certainly in Europe, while the US time notation is more
rare, you give something extra that is not needed for your
investigation.
While I consider anything with VB or .NET in it anathema, there
should still be no reason for date confusion today. There has
been an ISO standard for date and time format for many years.
Today is 2004-01-10, for example, with no ambiguities. The
(local) time is 07:13:30. In GMT we are at "2004-01-10 12:13:30".
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Hi CBFalconer
I find it a very good point and a pitty that it is not everywhere
implemented as that.
I think that the date implementation is so strange because some todays
languages are often started as learning tools in the USA or just as an USA
oriented scripting tool (The most worse in that in my eyes SQL).
However I find too it would be a giant step to better if that ISO standard
was default everywhere.
Cor While I consider anything with VB or .NET in it anathema, there
should still be no reason for date confusion today. There has
been an ISO standard for date and time format for many years.
Today is 2004-01-10, for example, with no ambiguities. The
(local) time is 07:13:30. In GMT we are at "2004-01-10 12:13:30".
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>... Edward G. Nilges <sp*********@yahoo.com> wrote: No, the *boxed* types inherit from object (via ValueType). This *is* an
important distinction.
OK, I accept it's an important distinction at run time. But my concern
is describing source, where it's meaningful to point out that a value
type can be, notationally an object.
<snip>
OK, can we agree that virtually a value type is an object?
I'm not sure I'd *quite* go with either of those (mostly because I
don't know what *exactly* you mean by "virtually" in the second one).
How about that a value type can be transparently viewed as an object? I
don't think it matters whether or not we agree exactly at this stage
though - we clearly understand the same things, fundamentally.
My only remaining question is what to tell training classes consisting
of Visual Basic 6 programmers, armed as usual with pitchforks and
torches and angry and upset about having to change, whether
"everything is an object".
Edward G. Nilges <sp*********@yahoo.com> wrote: I'm not sure I'd *quite* go with either of those (mostly because I
don't know what *exactly* you mean by "virtually" in the second one).
How about that a value type can be transparently viewed as an object? I
don't think it matters whether or not we agree exactly at this stage
though - we clearly understand the same things, fundamentally.
My only remaining question is what to tell training classes consisting
of Visual Basic 6 programmers, armed as usual with pitchforks and
torches and angry and upset about having to change, whether
"everything is an object".
I'd tell them the truth. The earlier people get into the idea of
references, reference types, values, value types and boxing, the better
IMO. It affects just about everything else you do.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Saqib Ali |
last post by:
Hello All,
I m not sure if this is the right place to ask for a critique. If not
please refer me to another group. Thanks.
I would a criqtique of the following website:...
|
by: TC |
last post by:
Are there any good sites or forums for a web critique? I went to
alt.html.critique and it's pretty dead.
|
by: bowsayge |
last post by:
Inspired by fb, Bowsayge decided to write a decimal integer
to binary string converter. Perhaps some of the experienced
C programmers here can critique it. It allocates probably
way too much...
|
by: christopher diggins |
last post by:
I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up
the following issues :
- unsafe code
- attributes
- garbage collection
-...
|
by: Eric |
last post by:
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...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
