Looking For Explanation Regarding Declaration Syntax

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello, I have a question I'm hoping someone can clarify for me. My question
regards the declaration of a variable/ array variable. Anyhow, I was
wondering if someone can explain the following declaration to me:

Dim sendBytes as [Byte]( ) = Encoding.ASCII.GetBytes("Is anybody
listening...")

It looks like type byte is an array. Is this correct? Also, what do the
brackets represent? I tried finding some type of explanation but is
unsuccessful. Would the following syntax be an alternative?

Dim sendBytes as Byte( ) = Encoding.ASCII.GetBytes("Is anybody listening...")

Thanks,
 
Thanks Mercer, OK, can someone now tell me in laymens term. You know I'm not
that smart...lol
--
TC


AMercer said:
The brackets indicate an 'escaped' name or identifier.

Terrance said:
Hello, I have a question I'm hoping someone can clarify for me. My question
regards the declaration of a variable/ array variable. Anyhow, I was
wondering if someone can explain the following declaration to me:

Dim sendBytes as [Byte]( ) = Encoding.ASCII.GetBytes("Is anybody
listening...")

It looks like type byte is an array. Is this correct? Also, what do the
brackets represent? I tried finding some type of explanation but is
unsuccessful. Would the following syntax be an alternative?

Dim sendBytes as Byte( ) = Encoding.ASCII.GetBytes("Is anybody listening...")

Thanks,
 
Terrance said:
Thanks Mercer, OK, can someone now tell me in laymens term. You know I'm not
that smart...lol

Putting square brackets around an identifier in VB allows you to use a
VB reserved word as a variable name. The example you provided does not
really need them. Here's an example:

Dim [String] As String = "Hello World"

MsgBox([String])
 
Thanks for the information that helps.
--
TC


Chris Dunaway said:
Terrance said:
Thanks Mercer, OK, can someone now tell me in laymens term. You know I'm not
that smart...lol

Putting square brackets around an identifier in VB allows you to use a
VB reserved word as a variable name. The example you provided does not
really need them. Here's an example:

Dim [String] As String = "Hello World"

MsgBox([String])
 
Hello Chris,

This feature is one of my personal pet peeves. Whichever genius over at
MSFT decided that people needed to use keywords as identifiers ought to be
shot.

-Boo
Terrance said:
Thanks Mercer, OK, can someone now tell me in laymens term. You know
I'm not that smart...lol
Putting square brackets around an identifier in VB allows you to use a
VB reserved word as a variable name. The example you provided does
not really need them. Here's an example:

Dim [String] As String = "Hello World"

MsgBox([String])
 
I have to agree with GhostinAK. It doesn't make much since to use a keyword
as a variable; it just confuses things. Interesting topic here....
--
TC


GhostInAK said:
Hello Chris,

This feature is one of my personal pet peeves. Whichever genius over at
MSFT decided that people needed to use keywords as identifiers ought to be
shot.

-Boo
Terrance said:
Thanks Mercer, OK, can someone now tell me in laymens term. You know
I'm not that smart...lol
Putting square brackets around an identifier in VB allows you to use a
VB reserved word as a variable name. The example you provided does
not really need them. Here's an example:

Dim [String] As String = "Hello World"

MsgBox([String])
 
GhostInAK said:
This feature is one of my personal pet peeves. Whichever genius over at
MSFT decided that people needed to use keywords as identifiers ought to be
shot.

So which keywords shouldn't be allowed to be used as identifiers - just
VB.NET ones, or VB.NET ones and C# ones and C++ ones? What about
languages which haven't been invented yet?

When multiple languages target the same platform and identifiers
declared in one language need to be usable in others, you really *have*
to have some way of saying "I know this is normally a keyword, but
treat it as an identifier for now".
 
Jon:

You make a good point that I didn't think about. It is unique how MS made
the languages in the .NET family compatible. However, I think the point that
some people were making was that; when we first start learning about
programming there were these rules that one had to follow so that the code
made since. However, I think that some people have thrown out rules that
cheapens the art of programming. Organizations are rushing programmers to
create applications more quickly which is o.k. but what about creating an app
were the next individual that comes behind you can say "Hey this code is
pretty cool...." I honestly think that we tend to make things more easier
which in the long run hurts us and our profession. Well, that's enough of me
being on my soap box. Thanks for the interesting comments everyone.
 
GhostInAK said:
This feature is one of my personal pet peeves. Whichever genius over at
MSFT decided that people needed to use keywords as identifiers ought to be
shot.

I wasn't making any statements about whether the practice was a good
one or not (I agree with you on this point), but the OP wanted to know
what the syntax meant.
 
Jon said:
So which keywords shouldn't be allowed to be used as identifiers - just
VB.NET ones, or VB.NET ones and C# ones and C++ ones? What about
languages which haven't been invented yet?

In this case, only VB keywords. You can use C# and C++ keywords in VB
as identifiers without any special syntax (other than those that happen
to match VB).
to have some way of saying "I know this is normally a keyword, but
treat it as an identifier for now".

How is this done in C#?
 
In this case, only VB keywords. You can use C# and C++ keywords in VB
as identifiers without any special syntax (other than those that happen
to match VB).


How is this done in C#?

As old as in all C derived languages. Play with the cases.

string String = "STRING";

Cor
 
Chris said:
In this case, only VB keywords. You can use C# and C++ keywords in VB
as identifiers without any special syntax (other than those that happen
to match VB).

The problem is using VB.NET keywords in a class library written in
another language which you use in VB.NET. Consider the following
example.

// Compiled in C#
namespace Example
{
public class Foo
{
public static int New = 0;
}
}

' Compiled in VB.NET
Imports Example

Module Module1

Sub Main()
Console.WriteLine(Foo.New) ' Error
Console.WriteLine(Foo.[New]) ' Correct
End Sub

End Module
How is this done in C#?

C# uses the @ prefix.
 
Cor said:
As old as in all C derived languages. Play with the cases.

string String = "STRING";

Cor

String is not a keyword in C#. That's why the that line compiles. A
better example is:

string @string = "STRING";
 
Chris Dunaway said:
In this case, only VB keywords. You can use C# and C++ keywords in VB
as identifiers without any special syntax (other than those that happen
to match VB).

So VB is "special" in that all languages should ban any VB keywords
from being identifiers, but they don't get the same treatment? I can't
say I'd favour that proposal.
How is this done in C#?

The @ sign:

string @int = "hello";
Console.WriteLine (@int);
 
Jon said:
So VB is "special" in that all languages should ban any VB keywords
from being identifiers, but they don't get the same treatment? I can't
say I'd favour that proposal.

Going further with this point I think it is more likely you'd actually
need to use verbatim identifiers in VB.NET than in C#. That's because
C#'s lowercase keywords would not conflict with Pascal cased public
identifiers. Whether I'm right or not may be a matter of debate, but
at least it's a reasonable hypothesis.

Brian
 
Jon said:
So VB is "special" in that all languages should ban any VB keywords
from being identifiers, but they don't get the same treatment? I can't
say I'd favour that proposal.

I've obviously missed your point. Why would other languages have to
ban anything since VB keywords are meaningless to C# and C++? I simply
meant that the square brackets are needed for VB where VB keywords are
used as identifiers. I'm not sure how that affects C# at all.
 
Chris Dunaway said:
I've obviously missed your point. Why would other languages have to
ban anything since VB keywords are meaningless to C# and C++? I simply
meant that the square brackets are needed for VB where VB keywords are
used as identifiers. I'm not sure how that affects C# at all.

The post I originally replied to said:

"Whichever genius over at MSFT decided that people needed to use
keywords as identifiers ought to be shot."

Now, if someone writing a C# class wants to call it MustInherit, it's
reasonable that they should be able to - it's not a C# keyword or
anything like that.

Now, if you *couldn't* use keywords as identifiers, class names etc,
then you wouldn't be able to use the MustInherit class from VB.NET. I
don't think that would be a good restriction. Do you?
 
Jon said:
The post I originally replied to said:

Thanks Jon, I went back and re-read the posts again and I understand
your point. I think I was having a foggy Monday!
 
Chris Dunaway said:
Thanks Jon, I went back and re-read the posts again and I understand
your point. I think I was having a foggy Monday!

Don't worry - I suspect I was less than lucid anyway. With young twins
in the house, I'm having a foggy *year*!
 
Back
Top