2 ways to initialize, what's the difference?

  • Thread starter Thread starter Zytan
  • Start date Start date
It's part of an idiom. If you don't want to use the idiom, then don't
(but, as others have said, consistency matters, so be consistent in
not using it).
Click to expand...

Ok, so it's an idiom. An expression whose meaning cannot be deduced
from the literal definitions and the arrangement of its parts. This
explains it. Thank you.
As Tom pointed out in another post, no one seems to have a problem
with ...

Dim A As String = "xyzzy"

Or ...

Dim A As String
A = "abracadabra"

... even though there's an implicit New somewhere (during
initialization).
Click to expand...

I didn't have a problem with it, until I found out that "New" is
hidden. But, now that I realize hiding "New" always happens, it's ok.
This is an interesting example, because it touches the notion that
VB.Net is idiosyncractic because of its many hystorical VB'isms.
Ironicaly, to a seasoned VB.Classic programmer, the "Dim X As New Y"
construct would be a very definitive *no*, because of the way it used
to work previously to VB.Net and the kind of code it generated. Yet,
in VB.Net it's a popular idiom and one that I -- even being a
"seasoned" VB programmer -- recommend, because there's *no* semantic
ambiguity in the short circuit. Personally I'd even recommend you not
using the "complete" syntax, due to verbosity.
Click to expand...

Agreed. Like I said, I can 'see' how the shortcut is 'ok'. I really
had no problems with it. Probably because of the lack of ambiguity,
as you said. Very well put.
I, personaly, really *abhor* the "New X() { ... }" syntax... *sigh*
(of course, no one has to condone my personal grievances).

The short circuit syntax seems perfectly clear to me and I am glad
it's clear to the compiler also. What I think is inconsistent is that
this short circuit can't be used outside a Dim (just as with strings):

Dim Args() As Integer
Args = {...}
Click to expand...

Ok, now that i know VB hides "New" all the time, I don't mind the lack
of "New" in the above anymore, especially now that I know what is
going on. If it consistently hides "New", that everything is fine.

But, yes, I dislike the inconsistancy as you mentioned above, as
well. Im glad to know I am not going crazy, but others have had these
thoughts, too.
I suggest you experiment with the short circuit in some of the next
snippets you'll have to produce. Or in the next project you'll start.
After using the short circuit in some real situations you'll be able
to decide if it's part of your vocabulary or not.
Click to expand...

Ok.

Much thanks for your indepth reply.

Zytan
 
It are all string operations; whatever you try to do with a string as part,
it will always create a new string. With one exception, that written in one
line a string will created as one line.

Example of the last

"a" & "b" & "c" written in one line will result direct in "abc" in more
lines that will be "ab" & "c".

Although this is not about that behaviour, it will be that, in any case
with the lightest change in your program.
Click to expand...

Ok. Understood. Thanks.

Zytan
 
Zytan said:
Tom, thanks for your indepth reply.


Ok. (I also believe Dim is outdated. It's like using LET in older
BASICs, but we were all glad we didnt have to use it, so no one did.)


I prefer to avoid this shortcut, too. But i have been using it to get
used to other people's code.


I see. Since the following makes obj2 an ArrayList, not an Object:
Dim obj2 As New ArrayList()


No. I do think of strings as classes, unlike integers and floating
point types that are natural types. You can make a string (or any
class) without "New"ing it. It just becomes a variable on the stack,
rather than dynamically allocated. So, i don't miss the lack of "New"
here.
Click to expand...

No, that's not right. An object is always allocated on the heap,
regardless of how it's created. The creation process is the same, even
if the syntax is different.
I notice that this works:
Dim arg2 As String = "test"
but this doesn't:
Dim arg3 As New String = "test"

This is confusing. Why can't i "New" that class if i want to?
Click to expand...

Yes, you can use New to create a string:

Dim arg3 As New String("test")
I obviously have no idea how the "New" keyword is used. I was thinking
it would be similar to what it means in C++.
Click to expand...

It is. It's just the VB syntax that is a bit confusing.
(Does C# share these
same issues? No, it looks like you have to use "New" in C#. Maybe I
should use C# instead.)
Click to expand...

That's not a bad idea at all. Knowing more than one programming language
gives a deeper knowledge to programming in general. So by knowing a bit
of C# you will also learn to understand VB.NET a bit better.
No, you can use this without the "New" keyword, as well:
Dim arg5 As String() = {"test", "2nd"}
Click to expand...

That is only when you have the declaration and the assignment in the
same statement.
Is this the same issue I was having with Object()? Let's see. Yes,
it is. Ok, so let's ignore Object() for now, since that was confusing
me. Let's deal with just String or Integer, since the above is the
same problem.


And the same can be done without "New", which normally is:
Dim i2 As Integer() = {4, 5, 6}
Click to expand...

Same there.
 
Now you're getting to the nitty-gritty.

The String type has no public constructors that don't take a parameter.
That's why you can't use

Dim arg3 As New String = "test"

or even:

Dim arg3 As New String

This behaviour also applys to Value types which, in general, don't have
public constructors at all.

System.String is a 'special-case' Reference type that exhibits behaviour
similar to Value Types. There are more but I can't remember them off the top
of my head.

A point here is that some of these 'foibles' are dictated by the CLR or the
Framework itself, rather that the language.


Zytan said:
Tom, thanks for your indepth reply.
Click to expand...
I notice that this works:
Dim arg2 As String = "test"
but this doesn't:
Dim arg3 As New String = "test"

This is confusing. Why can't i "New" that class if i want to? I
obviously have no idea how the "New" keyword is used. I was thinking
it would be similar to what it means in C++. (Does C# share these
same issues? No, it looks like you have to use "New" in C#. Maybe I
should use C# instead.)
Click to expand...

</snip>
 
No. I do think of strings as classes, unlike integers and floating
No, that's not right. An object is always allocated on the heap,
regardless of how it's created. The creation process is the same, even
if the syntax is different.
Click to expand...

Ok. So, "New" really is verbose, and it is hidden because it is
verbose. Now i uderstand why they hide it all of the time. But, it
makes it hard for a C guy to learn.

Thank you.
Yes, you can use New to create a string:

Dim arg3 As New String("test")
Click to expand...

Either way, there's a "New" behind the scenes allocating it on the
heap. Yes, I now get that "New String" is an attempt to invoke a
specific constructor. I was just messing with this before I came
here. Thanks.

It is. It's just the VB syntax that is a bit confusing.
Click to expand...

Or, it's that it can be hidden, and so when it appears, it seems that
it should be doing something different, but that's not the case.
That's not a bad idea at all. Knowing more than one programming language
gives a deeper knowledge to programming in general. So by knowing a bit
of C# you will also learn to understand VB.NET a bit better.
Click to expand...

I feel as though I could code VC# with no effort giving my knowledge
of C/C++ and the framework now. It seems the only thing holding me
back are the idioms of VB, and backwards compatibility issues we all
must pay for for "the greater good".

But, you're right, knowing both VB and C# is even better.
That is only when you have the declaration and the assignment in the
same statement.
Click to expand...

Right.

Thanks!

Zytan
 
The String type has no public constructors that don't take a parameter.
That's why you can't use

Dim arg3 As New String = "test"

or even:

Dim arg3 As New String

This behaviour also applys to Value types which, in general, don't have
public constructors at all.
Click to expand...

Right. I just noticed intellisence telling me this. The pieces are
coming together. The fact that I now know "New" is always there,
whether you see it or not, helps a lot.
System.String is a 'special-case' Reference type that exhibits behaviour
similar to Value Types. There are more but I can't remember them off the top
of my head.
Ok.

A point here is that some of these 'foibles' are dictated by the CLR or the
Framework itself, rather that the language.
Click to expand...

So, the same should be true in C# or J#, then.

Thanks

Zytan
 
A point here is that some of these 'foibles' are dictated by the CLR or
So, the same should be true in C# or J#, then.
Click to expand...

Not at all. C#, having been derived from C and C++ is a syntacticly precise
language. I don't know anything about J# or Java so I'm not qualified to
comment on that.

VB.NET being derived from VB which in turn was derived from BASIC does not
require the same precisenes of syntax. This was always one of 'features'
that made BASIC easy to learn. I not really interested in a debate on the
rigts, wrongs or indifferences of this - It just is - like the Pope is
catholic, the Kennedys are gun- shy and bears do stuff in the woods!

When the requirement to use Let for assignment was dropped from BASIC, we
all applauded but it was still inferred. It was what differentiated the
context of = as either an assignment operator or a comparison operator.

Likewise, in the case of 'New', if it's needed but you don't code it, it is
still inferred. This can be confirmed by inspecting the compiled IL.

Just a reminder that inspecting the IL could answer an awful lot of the
'issues' that you are raising.
 
Zytan said:
Ok, so, now im totally confused. :) These are all the same code:


I need to find a tutorial that explains this. Just knowing they make
the same IL is not good enough.
Click to expand...

Well, there's even 'Dim args() As Object = New Object() {strText}' missing
in the list.
 
Ok, so, there's:

Dim args As Object() = New Object() {strText}
Dim args() As Object = New Object() {strText}
Dim args As Object() = {strText}
Dim args() As Object = {strText}

For "args As Object()" vs "args() As Object":

A variable that is of type 'array of something' is the same as a
variable, which is an array, where each element is the same
something. It's hard to put into words, as it really doesn't make
sense to have "args()". The point of "As" is to say what the variable
'Is'. No wonder this is confusing. VB must be the only language that
allows two different syntax to make the same array.

As far as the missing "New Object()", it is just implied. Everything
in VB is "New"ed. So, to avoid being verbose, it's just a shortcut.

Ok, I think I got it. Now, why can't tutorials say all of this?

Thanks!!

Zytan
 
Zytan said:
No wonder this is confusing. VB must be the only
language that allows two different syntax to make the same array.
Click to expand...

If they (MSFT) left out "args() as object" people would complain why they
changed the syntax they were used to all the years.

If they left out "args as object()" people would complain because the type
of the variable (object array) should stand _after_ "As".

If they allow both, people complain that it is confusing.


So, everything is wrong (or right).


Armin
 
Not at all. C#, having been derived from C and C++ is a syntacticly precise
language. I don't know anything about J# or Java so I'm not qualified to
comment on that.
Click to expand...

Ok, so, it really is due to the syntax of the language. This is what
I thought.
VB.NET being derived from VB which in turn was derived from BASIC does not
require the same precisenes of syntax. This was always one of 'features'
that made BASIC easy to learn.
Click to expand...

Personally, I find it more difficult to learn when the syntax isn't
precise. Perhaps this is due to using languages like C++ where, say,
the position of "const" in a pointer declaration makes all the
different in the world. You can't just move things around as is.
Although, in many places you can, say "const int x;" and "int const
x;" mean the same thing. And, yeah, I dislike that just as I do with
BASIC's lack of discipline -- its language independent -- since it
makes me wonder if I'm missing something.
When the requirement to use Let for assignment was dropped from BASIC, we
all applauded but it was still inferred. It was what differentiated the
context of = as either an assignment operator or a comparison operator.
Right.

Likewise, in the case of 'New', if it's needed but you don't code it, it is
still inferred.
Click to expand...

Right. I see where you're coming from. It just seems to me that
"New" is such a big deal that it should be present. But, I guess the
reason VB exists is so that we aren't concerned with "newing" things,
making it not so great of a deal, demoting it to being a "Let".
Just a reminder that inspecting the IL could answer an awful lot of the
'issues' that you are raising.
Click to expand...

Yes, IL peeking can answer my concerns, but again, just because it
makes the same code, it doesn't explain 'why'. That's what is
important. You guys are helping me answer that question. So, thanks.

Zytan
 
If they (MSFT) left out "args() as object" people would complain why they
changed the syntax they were used to all the years.
Click to expand...

Ah, so "args() as object" was the old syntax. Now it makes sense why
it exists.
If they left out "args as object()" people would complain because the type
of the variable (object array) should stand _after_ "As".
Click to expand...

Exactly. This is the proper way.
If they allow both, people complain that it is confusing.
Click to expand...

Which is better than having people complain their code doesn't
complain.
So, everything is wrong (or right).
Click to expand...

They made the best choice. Their hands are tied due to backwards
compatibility.

Zytan
 
Armin,

Armin Zingler said:
If they (MSFT) left out "args() as object" people would complain why they
changed the syntax they were used to all the years.

If they left out "args as object()" people would complain because the type
of the variable (object array) should stand _after_ "As".

If they allow both, people complain that it is confusing.

So, everything is wrong (or right).
Click to expand...

That's right. However, I can live with both ways being available.
 
Zytan said:
Ok, so, there's:

Dim args As Object() = New Object() {strText}
Dim args() As Object = New Object() {strText}
Dim args As Object() = {strText}
Dim args() As Object = {strText}

For "args As Object()" vs "args() As Object":

A variable that is of type 'array of something' is the same as a
variable, which is an array, where each element is the same
something. It's hard to put into words, as it really doesn't make
sense to have "args()". The point of "As" is to say what the variable
'Is'. No wonder this is confusing. VB must be the only language that
allows two different syntax to make the same array.

As far as the missing "New Object()", it is just implied. Everything
in VB is "New"ed. So, to avoid being verbose, it's just a shortcut.

Ok, I think I got it. Now, why can't tutorials say all of this?

Thanks!!

Zytan
Click to expand...

Missing another way to initialize: use reflection :P

Just thought I'd throw in something else too!

Mythran
 
Zytan said:
Thanks! Now I have to look up what reflection is. :)

Zytan
Click to expand...

lol don't beat yourself up over reflection though. It's usage should be
limited to when you have no other alternatives than to use it. Check out
the System.Reflection namespace in the MSDN help.

HTH,
Mythran
 
And one more for good measure:

Dim integerArray As Integer() =
CType(Array.CreateInstance(GetType(Integer), 10), Integer())

will give you variable of type Integer() with 10 elements (i.e., subscripts
0 to 9).

This is not what Dim integerArray As Integer(9) does under the hood because
the compiled IL is different but it will allow you to think in terms of
array size rather than array upper bounds.
 
Back
Top