Bracketed types

[Mike]

Ok, this is all very simple to me now.

It all stems from the fact VB/VB.NET is not case sensitive language
when it cames to identifiers.

It is long standard practice in languages like C/C++ and I guess C# to
use semantics such as:

TYPE_NAME type_name
i.e.

HANDLE handle;
LPCSTR lpcstr;
TXYZ xyz;

Because you can't readily do this in VB, for inherit keywords or
keywords that might conflict with existing identifiers, the brackets,
including name spaces helps serve this purpose. Of course, the
compiler and intellisense can determine what is what, but for
readability this can help the human code reader.

Thanks for your input

--

The _only_ reason to use them is to use a keyword as an identifier, be
it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to use
the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

 

[Cor Ligthert[MVP]]

Like I was talking about in the first reply of this thread.

And to be sure I have used almost the same test as you, although with the
exception that I have inherited a textbox in the 'String' class
(For those who see this reply separated, it is awful code, that is why I did
not show it direct)

\\\
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object _
, ByVal e As System.EventArgs) Handles MyBase.Load

Dim myArr As [String]() = {New [String]}

Controls.Add(myArr(0))
End Sub
Public Class [String]
Inherits TextBox
End Class
End Class
///

Cor

The _only_ reason to use them is to use a keyword as an identifier, be it
a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the custom
type is imported (explicitly or implicitly), and you want to use the type
without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

 

[Cor Ligthert[MVP]]

Like I was talking about in the first reply of this thread.

And to be sure I have used almost the same test as you, although with the
exception that I have inherited a textbox in the 'String' class
(For those who see this reply separated, it is awful code, that is why I did
not show it direct)

\\\
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object _
, ByVal e As System.EventArgs) Handles MyBase.Load

Dim myArr As [String]() = {New [String]}

Controls.Add(myArr(0))
End Sub
Public Class [String]
Inherits TextBox
End Class
End Class
///

Cor

The _only_ reason to use them is to use a keyword as an identifier, be it
a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the custom
type is imported (explicitly or implicitly), and you want to use the type
without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

 

[Mike]

The _only_ reason to use them is to use a keyword as an identifier, be
it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to use
the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

This is my 3rd post, that wasn't posted.. hope it takes now.

I believe I understand the basic reason for it. VB is not case
sensitive with identifiers. It is common practice in C/C++ and I
guess C# to do things like

TYPE_NAME type_name

with clear type or variable recognition. Using brackets in VB.NET
helps with this and also to address conflicts with inherited keywords,
i.e. Next.

Anyway, thanks for everyone's input.

--

 

[Mike]

The _only_ reason to use them is to use a keyword as an identifier, be
it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to use
the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

This is my 3rd post, that wasn't posted.. hope it takes now.

I believe I understand the basic reason for it. VB is not case
sensitive with identifiers. It is common practice in C/C++ and I
guess C# to do things like

TYPE_NAME type_name

with clear type or variable recognition. Using brackets in VB.NET
helps with this and also to address conflicts with inherited keywords,
i.e. Next.

Anyway, thanks for everyone's input.

--

 

[Cor Ligthert[MVP]]

Mike,

No it solves things which you simply cannot do in C# which completely rely
on namespaces. However, I recognize it only as sugar.

It has nothing to do with case sensitivity, by instance a public properties
which are used in C# and C++ with the same names but written with different
cases are in those program languages unique identifier, but they are not CLI
compliant but you cannot solve this with these brackets.

However, because it can be used everywhere it can also be used in a wrong
way, like in the sample you have showed

Cor

The _only_ reason to use them is to use a keyword as an identifier, be
it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to use
the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

This is my 3rd post, that wasn't posted.. hope it takes now.

I believe I understand the basic reason for it. VB is not case sensitive
with identifiers. It is common practice in C/C++ and I guess C# to do
things like

TYPE_NAME type_name

with clear type or variable recognition. Using brackets in VB.NET helps
with this and also to address conflicts with inherited keywords, i.e.
Next.

Anyway, thanks for everyone's input.

 

[Cor Ligthert[MVP]]

Mike,

No it solves things which you simply cannot do in C# which completely rely
on namespaces. However, I recognize it only as sugar.

It has nothing to do with case sensitivity, by instance a public properties
which are used in C# and C++ with the same names but written with different
cases are in those program languages unique identifier, but they are not CLI
compliant but you cannot solve this with these brackets.

However, because it can be used everywhere it can also be used in a wrong
way, like in the sample you have showed

Cor

The _only_ reason to use them is to use a keyword as an identifier, be
it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to use
the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

This is my 3rd post, that wasn't posted.. hope it takes now.

I believe I understand the basic reason for it. VB is not case sensitive
with identifiers. It is common practice in C/C++ and I guess C# to do
things like

TYPE_NAME type_name

with clear type or variable recognition. Using brackets in VB.NET helps
with this and also to address conflicts with inherited keywords, i.e.
Next.

Anyway, thanks for everyone's input.

 

[Mike]

Mike,

No it solves things which you simply cannot do in C# which completely
rely on namespaces. However, I recognize it only as sugar.

It has nothing to do with case sensitivity, by instance a public
properties which are used in C# and C++ with the same names but
written with different cases are in those program languages unique
identifier, but they are not CLI compliant but you cannot solve
this with these brackets.

However, because it can be used everywhere it can also be used in a
wrong way, like in the sample you have showed

First, you seem to be a combative person so I hope by me continuing to
talk to you doesn't go off the deep end. Please take nothing I say the
wrong way and respect there are solid opinions here, you probably
won't be able to change. Thanks.

Understood, but you don't need brackets like this in C/C++/C# because
it is a long tradition to do thing things like:

TYPE_NAME type_name

which is akin to

dim type_name as TYPE_NAME

which can be confusing, hence a helper syntax is useful:

dim [type_name] as TYPE_NAME

Yes, there are reasons why it helps (i.e. like you must use a keyword,
like Next). I don't like it, but I can see the why now and can
probably find myself using it.

Whether that is GOOD or BAD, its a matter of debate. For me, its about
code readability and that's important.

That said, I'm also learning VB.NET and I recognize it has its own set
of semantics. I generally will never use something that common for a
language, isn't required and/or that make *things* difficult to
understand, not now, not next year, but 3, 5, 10 years down the road.
I'm an ex-arrogant APL programmer and there isn't is more cryptic
than APL and even in C/C++, one can be very cryptic. But today (at
least 10-15 years or so), I prefer code readability utmost over
anything else.

Thanks for your input.

--

The _only_ reason to use them is to use a keyword as an identifier,
be it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to

use the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

This is my 3rd post, that wasn't posted.. hope it takes now.

I believe I understand the basic reason for it. VB is not case
sensitive with identifiers. It is common practice in C/C++ and I
guess C# to do things like

TYPE_NAME type_name

with clear type or variable recognition. Using brackets in VB.NET
helps with this and also to address conflicts with inherited keywords,
i.e. Next.

Anyway, thanks for everyone's input.

 

[Mike]

Mike,

No it solves things which you simply cannot do in C# which completely
rely on namespaces. However, I recognize it only as sugar.

It has nothing to do with case sensitivity, by instance a public
properties which are used in C# and C++ with the same names but
written with different cases are in those program languages unique
identifier, but they are not CLI compliant but you cannot solve
this with these brackets.

However, because it can be used everywhere it can also be used in a
wrong way, like in the sample you have showed

First, you seem to be a combative person so I hope by me continuing to
talk to you doesn't go off the deep end. Please take nothing I say the
wrong way and respect there are solid opinions here, you probably
won't be able to change. Thanks.

Understood, but you don't need brackets like this in C/C++/C# because
it is a long tradition to do thing things like:

TYPE_NAME type_name

which is akin to

dim type_name as TYPE_NAME

which can be confusing, hence a helper syntax is useful:

dim [type_name] as TYPE_NAME

Yes, there are reasons why it helps (i.e. like you must use a keyword,
like Next). I don't like it, but I can see the why now and can
probably find myself using it.

Whether that is GOOD or BAD, its a matter of debate. For me, its about
code readability and that's important.

That said, I'm also learning VB.NET and I recognize it has its own set
of semantics. I generally will never use something that common for a
language, isn't required and/or that make *things* difficult to
understand, not now, not next year, but 3, 5, 10 years down the road.
I'm an ex-arrogant APL programmer and there isn't is more cryptic
than APL and even in C/C++, one can be very cryptic. But today (at
least 10-15 years or so), I prefer code readability utmost over
anything else.

Thanks for your input.

--

The _only_ reason to use them is to use a keyword as an identifier,
be it a
class name or a variable name.

One exception to this rule: A type's name is the same as one of the
keywords of the intrinsic types of VB, the namespace containing the
custom type is imported (explicitly or implicitly), and you want to

use the type without qualifying it by its namespace:

\\\
Private Sub Test()
Dim s As [String] ' Binds to the custom 'String' class.
Dim t As String ' Binds to 'System.String'.
End Sub
...
Public Class [String]
Public Value As String
End Class
///

This is my 3rd post, that wasn't posted.. hope it takes now.

I believe I understand the basic reason for it. VB is not case
sensitive with identifiers. It is common practice in C/C++ and I
guess C# to do things like

TYPE_NAME type_name

with clear type or variable recognition. Using brackets in VB.NET
helps with this and also to address conflicts with inherited keywords,
i.e. Next.

Anyway, thanks for everyone's input.

 

[Herfried K. Wagner [MVP]]

True, but I don't see the exception to the rule. With the first
declaration
you want to use the keyword as an identifier. This _is_ the rule that you
quoted.

Sorry, I misunderstood what you have written.

 

[Herfried K. Wagner [MVP]]

True, but I don't see the exception to the rule. With the first
declaration
you want to use the keyword as an identifier. This _is_ the rule that you
quoted.

Sorry, I misunderstood what you have written.

 

[Cor Ligthert[MVP]]

Mike,

I've made an example, in that is to the use of the bracket type in a way I
should.

\\\
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim theList As New List(Of theClass)
For i = 0 To 255
theList.Add(New theClass)
theList(i).Decimal = (i).ToString
theList(i).String = ChrW(i)
Next
Dim dgv As New DataGridView
Controls.Add(dgv)
Dim db As New BindingSource
db.DataSource = theList
dgv.DataSource = db
End Sub
Private Class theClass
Private _Decimal As String
Private _String As String
Public Property [Decimal]() As String
Get
Return _Decimal
End Get
Set(ByVal value As String)
_Decimal = value
End Set
End Property
Public Property [String]() As String
Get
Return _String
End Get
Set(ByVal value As String)
_String = value
End Set
End Property
End Class
End Class
///

Cor

 

[Cor Ligthert[MVP]]

Mike,

I've made an example, in that is to the use of the bracket type in a way I
should.

\\\
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim theList As New List(Of theClass)
For i = 0 To 255
theList.Add(New theClass)
theList(i).Decimal = (i).ToString
theList(i).String = ChrW(i)
Next
Dim dgv As New DataGridView
Controls.Add(dgv)
Dim db As New BindingSource
db.DataSource = theList
dgv.DataSource = db
End Sub
Private Class theClass
Private _Decimal As String
Private _String As String
Public Property [Decimal]() As String
Get
Return _Decimal
End Get
Set(ByVal value As String)
_Decimal = value
End Set
End Property
Public Property [String]() As String
Get
Return _String
End Get
Set(ByVal value As String)
_String = value
End Set
End Property
End Class
End Class
///

Cor

 

[Mike]

Good Example.

The main reason in my original question was if there was a *technical
need* for it over and beyond what is now clear is a developer's desire
to use identifiers that make sense to him but may conflict with
keywords. There is no technical need for them other than to maintain
some level of readability or usage to replace a keyword and/or resolve
compilation translations.

IOW, you did't have to use Decimal or String as variable, member or
property identifiers. That was your human choice. The next person
could of used:

Number, AsciiCode
Literal, Character

etc.

I thought there was some "base" or anonymous or functor like concept
related to it because I saw it used and didn't quite see why. But it
has nothing to do with that.

Being a compiler writer, it all make sense why it exist in VB.NET.

Try this: Create an interface in the IDE:

Public Interface iTraversal
Function [First](Of T)() As Boolean
Function [Next](Of T)() As Boolean
Function [Prev](Of T)() As Boolean
Function [Last](Of T)() As Boolean
End Interface

Then type in the IDE:

Public Class FOOBAR : implements iTraversal [PRESS ENTER]

and you will see the IDE automatically inject code the implementation
stubs functions:

Public Class FOOBAR : implements iTraversal
Public Function First(Of T)() As Boolean Implements ITraversal.First
End Function
Public Function [Next](Of T)() As Boolean Implements ITraversal.Next
End Function
Public Function Prev(Of T)() As Boolean Implements ITraversal.Prev
End Function
Public Function Last(Of T)() As Boolean Implements ITraversal.Last
End Function
End Class

and you will see it will strip the brackets for all keeping one
bracketed that conflicts with the inherit keyword next.

That tells me all I need to know about VB.NET brackets

Thanks again.

 

[Mike]

Good Example.

The main reason in my original question was if there was a *technical
need* for it over and beyond what is now clear is a developer's desire
to use identifiers that make sense to him but may conflict with
keywords. There is no technical need for them other than to maintain
some level of readability or usage to replace a keyword and/or resolve
compilation translations.

IOW, you did't have to use Decimal or String as variable, member or
property identifiers. That was your human choice. The next person
could of used:

Number, AsciiCode
Literal, Character

etc.

I thought there was some "base" or anonymous or functor like concept
related to it because I saw it used and didn't quite see why. But it
has nothing to do with that.

Being a compiler writer, it all make sense why it exist in VB.NET.

Try this: Create an interface in the IDE:

Public Interface iTraversal
Function [First](Of T)() As Boolean
Function [Next](Of T)() As Boolean
Function [Prev](Of T)() As Boolean
Function [Last](Of T)() As Boolean
End Interface

Then type in the IDE:

Public Class FOOBAR : implements iTraversal [PRESS ENTER]

and you will see the IDE automatically inject code the implementation
stubs functions:

Public Class FOOBAR : implements iTraversal
Public Function First(Of T)() As Boolean Implements ITraversal.First
End Function
Public Function [Next](Of T)() As Boolean Implements ITraversal.Next
End Function
Public Function Prev(Of T)() As Boolean Implements ITraversal.Prev
End Function
Public Function Last(Of T)() As Boolean Implements ITraversal.Last
End Function
End Class

and you will see it will strip the brackets for all keeping one
bracketed that conflicts with the inherit keyword next.

That tells me all I need to know about VB.NET brackets

Thanks again.

 

[Andrew Morton]

The main reason in my original question was if there was a *technical
need* for it over and beyond what is now clear is a developer's desire
to use identifiers that make sense to him but may conflict with
keywords. There is no technical need for them other than to maintain
some level of readability or usage to replace a keyword and/or resolve
compilation translations.

You have to use square brackets around Enum in the following line:

Dim dataFiles([Enum].GetValues(GetType(Info.Stuff.Things)).Length - 1) As
String

as without them it expects an expression.

Andrew

 

[Andrew Morton]

The main reason in my original question was if there was a *technical
need* for it over and beyond what is now clear is a developer's desire
to use identifiers that make sense to him but may conflict with
keywords. There is no technical need for them other than to maintain
some level of readability or usage to replace a keyword and/or resolve
compilation translations.

You have to use square brackets around Enum in the following line:

Dim dataFiles([Enum].GetValues(GetType(Info.Stuff.Things)).Length - 1) As
String

as without them it expects an expression.

Andrew

 

[Cor Ligthert[MVP]]

Mike,

It was not my personal choice, the DataGridView sets (as you don't do a lot
of work) by default the names of the properties in the header.

Maybe had in this case been Char better then String, but that I thought
about when I had send it.

The grid shows all decimal values with its equivalent char on the computer
for the first 255 decimals.



Cor

Good Example.

The main reason in my original question was if there was a *technical
need* for it over and beyond what is now clear is a developer's desire to
use identifiers that make sense to him but may conflict with keywords.
There is no technical need for them other than to maintain some level of
readability or usage to replace a keyword and/or resolve compilation
translations.

IOW, you did't have to use Decimal or String as variable, member or
property identifiers. That was your human choice. The next person could
of used:

Number, AsciiCode
Literal, Character

etc.

I thought there was some "base" or anonymous or functor like concept
related to it because I saw it used and didn't quite see why. But it has
nothing to do with that.

Being a compiler writer, it all make sense why it exist in VB.NET.

Try this: Create an interface in the IDE:

Public Interface iTraversal
Function [First](Of T)() As Boolean
Function [Next](Of T)() As Boolean
Function [Prev](Of T)() As Boolean
Function [Last](Of T)() As Boolean
End Interface

Then type in the IDE:

Public Class FOOBAR : implements iTraversal [PRESS ENTER]

and you will see the IDE automatically inject code the implementation
stubs functions:

Public Class FOOBAR : implements iTraversal
Public Function First(Of T)() As Boolean Implements ITraversal.First
End Function
Public Function [Next](Of T)() As Boolean Implements ITraversal.Next
End Function
Public Function Prev(Of T)() As Boolean Implements ITraversal.Prev
End Function
Public Function Last(Of T)() As Boolean Implements ITraversal.Last
End Function
End Class

and you will see it will strip the brackets for all keeping one bracketed
that conflicts with the inherit keyword next.

That tells me all I need to know about VB.NET brackets

Thanks again.

Mike,

I've made an example, in that is to the use of the bracket type in a way
I should.

\\\
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles
MyBase.Load
Dim theList As New List(Of theClass)
For i = 0 To 255
theList.Add(New theClass)
theList(i).Decimal = (i).ToString
theList(i).String = ChrW(i)
Next
Dim dgv As New DataGridView
Controls.Add(dgv)
Dim db As New BindingSource
db.DataSource = theList
dgv.DataSource = db
End Sub
Private Class theClass
Private _Decimal As String
Private _String As String
Public Property [Decimal]() As String
Get
Return _Decimal
End Get
Set(ByVal value As String)
_Decimal = value
End Set
End Property
Public Property [String]() As String
Get
Return _String
End Get
Set(ByVal value As String)
_String = value
End Set
End Property
End Class
End Class
///

Cor

 

[Cor Ligthert[MVP]]

Mike,

It was not my personal choice, the DataGridView sets (as you don't do a lot
of work) by default the names of the properties in the header.

Maybe had in this case been Char better then String, but that I thought
about when I had send it.

The grid shows all decimal values with its equivalent char on the computer
for the first 255 decimals.



Cor

Good Example.

The main reason in my original question was if there was a *technical
need* for it over and beyond what is now clear is a developer's desire to
use identifiers that make sense to him but may conflict with keywords.
There is no technical need for them other than to maintain some level of
readability or usage to replace a keyword and/or resolve compilation
translations.

IOW, you did't have to use Decimal or String as variable, member or
property identifiers. That was your human choice. The next person could
of used:

Number, AsciiCode
Literal, Character

etc.

I thought there was some "base" or anonymous or functor like concept
related to it because I saw it used and didn't quite see why. But it has
nothing to do with that.

Being a compiler writer, it all make sense why it exist in VB.NET.

Try this: Create an interface in the IDE:

Public Interface iTraversal
Function [First](Of T)() As Boolean
Function [Next](Of T)() As Boolean
Function [Prev](Of T)() As Boolean
Function [Last](Of T)() As Boolean
End Interface

Then type in the IDE:

Public Class FOOBAR : implements iTraversal [PRESS ENTER]

and you will see the IDE automatically inject code the implementation
stubs functions:

Public Class FOOBAR : implements iTraversal
Public Function First(Of T)() As Boolean Implements ITraversal.First
End Function
Public Function [Next](Of T)() As Boolean Implements ITraversal.Next
End Function
Public Function Prev(Of T)() As Boolean Implements ITraversal.Prev
End Function
Public Function Last(Of T)() As Boolean Implements ITraversal.Last
End Function
End Class

and you will see it will strip the brackets for all keeping one bracketed
that conflicts with the inherit keyword next.

That tells me all I need to know about VB.NET brackets

Thanks again.

Mike,

I've made an example, in that is to the use of the bracket type in a way
I should.

\\\
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles
MyBase.Load
Dim theList As New List(Of theClass)
For i = 0 To 255
theList.Add(New theClass)
theList(i).Decimal = (i).ToString
theList(i).String = ChrW(i)
Next
Dim dgv As New DataGridView
Controls.Add(dgv)
Dim db As New BindingSource
db.DataSource = theList
dgv.DataSource = db
End Sub
Private Class theClass
Private _Decimal As String
Private _String As String
Public Property [Decimal]() As String
Get
Return _Decimal
End Get
Set(ByVal value As String)
_Decimal = value
End Set
End Property
Public Property [String]() As String
Get
Return _String
End Get
Set(ByVal value As String)
_String = value
End Set
End Property
End Class
End Class
///

Cor

 

[Cor Ligthert[MVP]]

Now I see you saw that



Cor