Bracketed types

[Cor Ligthert[MVP]]

Now I see you saw that



Cor

 

[Mike]

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

Ok, thanks for sharing this.

But why wouldn't this work Andrew?

Dim dataFiles(Info.Stuff.Things.GetValues( _
GetType(Info.Stuff.Things)).Length - 1) As String

What am I missing? Is it more optimal, more efficient, abeit maybe
not more readable, using [ENUM]?

Both objects are static objects so more importantly, one does not have
to explicitly instantiate the object to access its methods. In factm
the compiler will issue a warning when using a dynamic reference to a
ENUM type:

dim things as New Info.Stuff.Things
Dim dataFiles(things.GetValues( _
GetType(Info.Stuff.Things)).Length - 1) As String


In principle, enumerated variables, objects tend to be predefined at
compiled time, readonly at runtime hence IMO more optimal to burn it
as a static object.

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed that
[String] can be used defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?


--

 

[Mike]

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

Ok, thanks for sharing this.

But why wouldn't this work Andrew?

Dim dataFiles(Info.Stuff.Things.GetValues( _
GetType(Info.Stuff.Things)).Length - 1) As String

What am I missing? Is it more optimal, more efficient, abeit maybe
not more readable, using [ENUM]?

Both objects are static objects so more importantly, one does not have
to explicitly instantiate the object to access its methods. In factm
the compiler will issue a warning when using a dynamic reference to a
ENUM type:

dim things as New Info.Stuff.Things
Dim dataFiles(things.GetValues( _
GetType(Info.Stuff.Things)).Length - 1) As String


In principle, enumerated variables, objects tend to be predefined at
compiled time, readonly at runtime hence IMO more optimal to burn it
as a static object.

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed that
[String] can be used defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?


--

 

[Mike]

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed that
[String] can be user defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different reference
to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

--

 

[Mike]

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed that
[String] can be user defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different reference
to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

--

 

[Andrew Morton]

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.

Ok, thanks for sharing this.

But why wouldn't this work Andrew?

Dim dataFiles(Info.Stuff.Things.GetValues( _
GetType(Info.Stuff.Things)).Length - 1) As String

That works too. Hey, all I thought you wanted was an example of where square
brackets are required

What am I missing? Is it more optimal, more efficient, abeit maybe
not more readable, using [ENUM]?

Both objects are static objects so more importantly, one does not have
to explicitly instantiate the object to access its methods.

Perhaps it's a style thing to keep it aligned with the idea of accessing a
shared member directly from the base class rather than through an instance.
If everything's consistent, I get less confused. Why they couldn't just give
us .Count for enums I do not know.

Andrew

 

[Andrew Morton]

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.

Ok, thanks for sharing this.

But why wouldn't this work Andrew?

Dim dataFiles(Info.Stuff.Things.GetValues( _
GetType(Info.Stuff.Things)).Length - 1) As String

That works too. Hey, all I thought you wanted was an example of where square
brackets are required

What am I missing? Is it more optimal, more efficient, abeit maybe
not more readable, using [ENUM]?

Both objects are static objects so more importantly, one does not have
to explicitly instantiate the object to access its methods.

Perhaps it's a style thing to keep it aligned with the idea of accessing a
shared member directly from the base class rather than through an instance.
If everything's consistent, I get less confused. Why they couldn't just give
us .Count for enums I do not know.

Andrew

 

[Mike]

That works too. Hey, all I thought you wanted was an example of where square
brackets are required

But it wasn't technically required.

What am I missing? Is it more optimal, more efficient, abeit maybe
not more readable, using [ENUM]?

Both objects are static objects so more importantly, one does not have
to explicitly instantiate the object to access its methods.

Perhaps it's a style thing to keep it aligned with the idea of accessing a
shared member directly from the base class rather than through an instance.

Right, its what makes it easier for the developer to understand.

If everything's consistent, I get less confused.

Thats my approach too. VB.NET is a different animal though, to me.
I get excited using it and then at times I wonder I must be
masochist or crazy to redo years of solid code and work. The good
news, if I followed Anders presentations right, its all headed to a
common understanding of all languages and since VB.NET has been
blessed to gain the power of C/C++ and javascript prototyping while
keeping its beauty for easier coding, it will be more consistent down
the road.

My wishlist are:

- add // inline commenting (easier to borrow comments)
- get rid of _ continuation lines (in VS2010, I read)
- add self or this logic to class object, this is still
throwing me off.
- add automatic contructor/destructor (maybe when I
understand VB.NET classes better, it will be ok, its
just odd that some classes need NEW and others don't).
- Definitely make type casting easier or automatic.
- add more pragmas (like inline strict on/off)

Why they couldn't just give us .Count for enums I do not know.

Yeah, I hate when classes used Count or Length <g> I guess the reason
is that its borrowed from preexising classes in other languages. When
ported to .NET, the field names are kept.

--

 

[Mike]

That works too. Hey, all I thought you wanted was an example of where square
brackets are required

But it wasn't technically required.

What am I missing? Is it more optimal, more efficient, abeit maybe
not more readable, using [ENUM]?

Both objects are static objects so more importantly, one does not have
to explicitly instantiate the object to access its methods.

Perhaps it's a style thing to keep it aligned with the idea of accessing a
shared member directly from the base class rather than through an instance.

Right, its what makes it easier for the developer to understand.

If everything's consistent, I get less confused.

Thats my approach too. VB.NET is a different animal though, to me.
I get excited using it and then at times I wonder I must be
masochist or crazy to redo years of solid code and work. The good
news, if I followed Anders presentations right, its all headed to a
common understanding of all languages and since VB.NET has been
blessed to gain the power of C/C++ and javascript prototyping while
keeping its beauty for easier coding, it will be more consistent down
the road.

My wishlist are:

- add // inline commenting (easier to borrow comments)
- get rid of _ continuation lines (in VS2010, I read)
- add self or this logic to class object, this is still
throwing me off.
- add automatic contructor/destructor (maybe when I
understand VB.NET classes better, it will be ok, its
just odd that some classes need NEW and others don't).
- Definitely make type casting easier or automatic.
- add more pragmas (like inline strict on/off)

Why they couldn't just give us .Count for enums I do not know.

Yeah, I hate when classes used Count or Length <g> I guess the reason
is that its borrowed from preexising classes in other languages. When
ported to .NET, the field names are kept.

--

 

[Armin Zingler]

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed
that [String] can be user defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

You are using the _keyword_ Enum because you do not use [Enum]. The keyword
Enum can not be used in this context. Enum can only be used with the
declaration of a new Enum:

Enum MyEnum
End Enum


Enum.Whatever is not a valid context for the Enum keyword. IOW, you can not
change the fact that it is a keyword by using it in a different (invalid)
context.


Armin

 

[Armin Zingler]

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed
that [String] can be user defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

You are using the _keyword_ Enum because you do not use [Enum]. The keyword
Enum can not be used in this context. Enum can only be used with the
declaration of a new Enum:

Enum MyEnum
End Enum


Enum.Whatever is not a valid context for the Enum keyword. IOW, you can not
change the fact that it is a keyword by using it in a different (invalid)
context.


Armin

 

[Mike]

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed
that [String] can be user defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

You are using the _keyword_ Enum because you do not use [Enum]. The keyword
Enum can not be used in this context. Enum can only be used with the
declaration of a new Enum:

Enum MyEnum
End Enum

Enum.Whatever is not a valid context for the Enum keyword. IOW, you can not
change the fact that it is a keyword by using it in a different (invalid)
context.

I wasn't trying to change the semantics. The point is that there is
only one way to use it here. [ENUM] is telling the compiler to access
the static object methods which take the type you are working with, in
the say way:

ARRAY.method()
DATETIME.method()

and others can be used with "bracketizing" them.

Overall, [ENUM].method is not required. Just reference the enumerated
object you are working with.

If the IL shows that this created a local anonymous instance, then
using [ENUM] is more efficient.

--

 

[Mike]

Finally, I think, as Armin suggested, its a "compiler thing" <g> Why
[Enum] but not [DateTime] or other base classes? Herfield showed
that [String] can be user defined. [ENUM] too as I explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

You are using the _keyword_ Enum because you do not use [Enum]. The keyword
Enum can not be used in this context. Enum can only be used with the
declaration of a new Enum:

Enum MyEnum
End Enum

Enum.Whatever is not a valid context for the Enum keyword. IOW, you can not
change the fact that it is a keyword by using it in a different (invalid)
context.

I wasn't trying to change the semantics. The point is that there is
only one way to use it here. [ENUM] is telling the compiler to access
the static object methods which take the type you are working with, in
the say way:

ARRAY.method()
DATETIME.method()

and others can be used with "bracketizing" them.

Overall, [ENUM].method is not required. Just reference the enumerated
object you are working with.

If the IL shows that this created a local anonymous instance, then
using [ENUM] is more efficient.

--

 

[Armin Zingler]

Mike wrote:

Finally, I think, as Armin suggested, its a "compiler thing" <g>
Why [Enum] but not [DateTime] or other base classes? Herfield
showed that [String] can be user defined. [ENUM] too as I
explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

You are using the _keyword_ Enum because you do not use [Enum]. The
keyword Enum can not be used in this context. Enum can only be used
with the declaration of a new Enum:

Enum MyEnum
End Enum

Enum.Whatever is not a valid context for the Enum keyword. IOW, you
can not change the fact that it is a keyword by using it in a
different (invalid) context.

I wasn't trying to change the semantics. The point is that there is
only one way to use it here.

This indicates that you expect a context specific behavior.

[ENUM] is telling the compiler to access
the static object methods which take the type you are working with, in
the say way:

ARRAY.method()
DATETIME.method()

and others can be used with "bracketizing" them.

You mean _without_? Yes, because Array is not a keyword.

Overall, [ENUM].method is not required. Just reference the enumerated
object you are working with.

If the IL shows that this created a local anonymous instance, then
using [ENUM] is more efficient.

I fail to see the point here.


Armin

 

[Armin Zingler]

Mike wrote:

Finally, I think, as Armin suggested, its a "compiler thing" <g>
Why [Enum] but not [DateTime] or other base classes? Herfield
showed that [String] can be user defined. [ENUM] too as I
explored.

But if the compiler saw:

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

What other possible translation could that be but a different
reference to the ENUM class shared static methods?

Sorry, I meant "a DIRECT reference to the ......"

You are using the _keyword_ Enum because you do not use [Enum]. The
keyword Enum can not be used in this context. Enum can only be used
with the declaration of a new Enum:

Enum MyEnum
End Enum

Enum.Whatever is not a valid context for the Enum keyword. IOW, you
can not change the fact that it is a keyword by using it in a
different (invalid) context.

I wasn't trying to change the semantics. The point is that there is
only one way to use it here.

This indicates that you expect a context specific behavior.

[ENUM] is telling the compiler to access
the static object methods which take the type you are working with, in
the say way:

ARRAY.method()
DATETIME.method()

and others can be used with "bracketizing" them.

You mean _without_? Yes, because Array is not a keyword.

Overall, [ENUM].method is not required. Just reference the enumerated
object you are working with.

If the IL shows that this created a local anonymous instance, then
using [ENUM] is more efficient.

I fail to see the point here.


Armin

 

[Mike]

Overall, [ENUM].method is not required. Just reference the enumerated
object you are working with.

If the IL shows that this created a local anonymous instance, then
using [ENUM] is more efficient.

I fail to see the point here.

My original quest was to find out if there was a some technical reason
for it. I am finding there is none and purely for code semantics.

In the case of [ENUM], whether or not there is an code optimization
for speed or size as justification to use [ENUM] over using the direct
identifier:

[ENUM].GetValues(GetType(enumObject))
enumObject.GetValues(GetType(enumObject))

I will venture there is no difference here in the OP codes generated
Of course, I verified it <g>. The compiler will now to use the same
static object.

My point is AFAICT, there is no technical need for it other than
wanting to use the same "keyword" for your own usage. In my opinion,
its whats make "code sense" to you (speaking in general). I prefer
the latter and avoid any non-consistent usage of brackets.

If I am not explaining myself, maybe this example will.

Suppose I wanted to create a traversal class, or interface. In these
objects, you will normally have 4 fundamental methods that do the
following actions:

First
Next
Prev
Last

because that is what you normally see in traversal ideas.

Well, if you wanted to use this group of consistent names, Next is a
VB.NET keyword conflict so you need to use [Next]. Or we can be more
consistent and use a different set of names:

GetFirst
GetNext
GetPrev
GetLast

or

MoveFirst
MoveNext
MovePrev
MoveLast


etc. I prefer the GetXXXX group over having to use [Next] as the odd
ball method name in that group.

Understand?

Its really not a big deal, the thread has run its course.

--

 

[Mike]

Overall, [ENUM].method is not required. Just reference the enumerated
object you are working with.

If the IL shows that this created a local anonymous instance, then
using [ENUM] is more efficient.

I fail to see the point here.

My original quest was to find out if there was a some technical reason
for it. I am finding there is none and purely for code semantics.

In the case of [ENUM], whether or not there is an code optimization
for speed or size as justification to use [ENUM] over using the direct
identifier:

[ENUM].GetValues(GetType(enumObject))
enumObject.GetValues(GetType(enumObject))

I will venture there is no difference here in the OP codes generated
Of course, I verified it <g>. The compiler will now to use the same
static object.

My point is AFAICT, there is no technical need for it other than
wanting to use the same "keyword" for your own usage. In my opinion,
its whats make "code sense" to you (speaking in general). I prefer
the latter and avoid any non-consistent usage of brackets.

If I am not explaining myself, maybe this example will.

Suppose I wanted to create a traversal class, or interface. In these
objects, you will normally have 4 fundamental methods that do the
following actions:

First
Next
Prev
Last

because that is what you normally see in traversal ideas.

Well, if you wanted to use this group of consistent names, Next is a
VB.NET keyword conflict so you need to use [Next]. Or we can be more
consistent and use a different set of names:

GetFirst
GetNext
GetPrev
GetLast

or

MoveFirst
MoveNext
MovePrev
MoveLast


etc. I prefer the GetXXXX group over having to use [Next] as the odd
ball method name in that group.

Understand?

Its really not a big deal, the thread has run its course.

--

 

[Branco]

Andrew Morton wrote:

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.

Notice that each element in the program text is first "tokenized"
before being analyzed in the context of the syntax rules that govern
the VB.Net language (these two phases -- converting text into tokens
and analyzing the syntactic structure -- are known as lexing and
parsing, respectivelly). When the lexer reaches the position just
after that first open parenthesis, it probably sees "Enum" and
generates a token that says "Enum Keyword". Checking the parsing
rules, the parser will never find one that says "an expression may be
the keyword enum followed by a dot followed by members". On the other
hand, it will probably have a rule that says "an expression may be an
identifier followed by a dot followed by members". That's why you need
to disambiguiate so the compiler (actually the lexer) knows that the
next element is a regular identifier, not the enum keyword.

It's more complicated than that, of course. The lexer probably knows
that checking for keywords is valid after an open parenthesis, but
will never be valid after a dot (that's why you don't need brackets if
you use System.Enum instead of just Enum).

Hope this helps.

Regards,

Branco.

 

[Branco]

Andrew Morton wrote:

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.

Notice that each element in the program text is first "tokenized"
before being analyzed in the context of the syntax rules that govern
the VB.Net language (these two phases -- converting text into tokens
and analyzing the syntactic structure -- are known as lexing and
parsing, respectivelly). When the lexer reaches the position just
after that first open parenthesis, it probably sees "Enum" and
generates a token that says "Enum Keyword". Checking the parsing
rules, the parser will never find one that says "an expression may be
the keyword enum followed by a dot followed by members". On the other
hand, it will probably have a rule that says "an expression may be an
identifier followed by a dot followed by members". That's why you need
to disambiguiate so the compiler (actually the lexer) knows that the
next element is a regular identifier, not the enum keyword.

It's more complicated than that, of course. The lexer probably knows
that checking for keywords is valid after an open parenthesis, but
will never be valid after a dot (that's why you don't need brackets if
you use System.Enum instead of just Enum).

Hope this helps.

Regards,

Branco.