|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Bracketed typesCan someone explain why/when someone would use a type with square
brackets? For example im myArr As [String]() = {"1", "2", "3"} vs im myArr As String() = {"1", "2", "3"} Whats the difference? -- Mike,
Mostly it has not sense and can even give wrong results. The brackets are meant that if you have created your own class string (which is to inside the brackets) Can use that one. In that way you can make from the [String] by instance a combobox. But in my idea only a fool will use that. You see this often in the first VB Net samples as they are made by C++ writers. (And it makes your code of course very sophisticated (in a way I don't like)) Cor "Mike" <unkn***@unknown.tv> schrieb: In the sample above, it doesn't make a difference. The brackets around a > Can someone explain why/when someone would use a type with square > brackets? > > For example > > im myArr As [String]() = {"1", "2", "3"} > vs > im myArr As String() = {"1", "2", "3"} > > Whats the difference? keyword ('String' is actually a keyword) remove the keyword semantics. Consequently it's possible to use the keyswords as identifiers by surrounding them with brackets: \\\ Dim [Next] As Foo /// -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://dotnet.mvps.org/dotnet/faqs/> Herfried K. Wagner [MVP] wrote:
Show quoteHide quote > "Mike" <unkn***@unknown.tv> schrieb: I think I see. So basically, its nothing more than to help one not >> Can someone explain why/when someone would use a type with square >> brackets? >> >> For example >> >> dim myArr As [String]() = {"1", "2", "3"} >> vs >> dim myArr As String() = {"1", "2", "3"} >> >> Whats the difference? > > In the sample above, it doesn't make a difference. The brackets around > a keyword ('String' is actually a keyword) remove the keyword semantics. > Consequently it's possible to use the keyswords as identifiers by > surrounding them with brackets: > > \\\ > Dim [Next] As Foo > /// confuse the mixing of a variable name as keywords or type, i.e. Dim string as STRING < --- compiler error dim [String] as String Dim [random] As New Random(2000) or Dim myClass As MyClass which compiles, but it will help to bracket it to make it more understood: Dim [myClass] As MyClass Right? I've been doing "generic" types more, like in this function to convert any object or structure field members to XML Function FieldsToXML(Of T)(ByVal obj As T) As String Would it be better to do? Function MsgHeaderToXML(Of [T])(ByVal Obj As [T]) As String Just to make it easier to understand it is a type? -- Mike wrote:
> Random is not a keyword, therefore> I think I see. So basically, its nothing more than to help one not > confuse the mixing of a variable name as keywords or type, i.e. > > Dim string as STRING < --- compiler error > dim [String] as String > Dim [random] As New Random(2000) Dim random As New Random(2000) works also. > Does not compile here because myClass is a keyword.> or > > Dim myClass As MyClass > > which compiles, > I've been doing "generic" types more, like in this function to convert No, the compiler knows that it's a type even without the brackets. :-) The> any object or structure field members to XML > > Function FieldsToXML(Of T)(ByVal obj As T) As String > > Would it be better to do? > > Function MsgHeaderToXML(Of [T])(ByVal Obj As [T]) As String > > Just to make it easier to understand it is a type? brackets enable you to use identifieres that are (reserved) keywords. That's all. If the identifier is not a keyword, it is not necessary to use brackets. It doesn't hurt but it's as useful as writing a = (((((1+2))))) Works also. ;-) Armin Armin Zingler wrote:
Show quoteHide quote > Mike wrote: hmmm, then I don't yet understand. I said that because I tried this:>> >> I think I see. So basically, its nothing more than to help one not >> confuse the mixing of a variable name as keywords or type, i.e. >> >> Dim string as STRING < --- compiler error >> dim [String] as String >> Dim [random] As New Random(2000) > > Random is not a keyword, therefore > > Dim random As New Random(2000) > > works also. > >> >> or >> >> Dim myClass As MyClass >> >> which compiles, > > Does not compile here because myClass is a keyword. imports Wildcat.Net.Server ... Dim wcserverapi As WcServerAPI Dim ni1 As WcServerAPI.TwcNodeInfo Dim ni2 As [WcServerAPI].TwcNodeInfo WcServerAPI is a class in my wildcat.net.server.dll It all compiled. I understand the compiler (the compiler knows <g>) is using the CLASS WcServerAPI for ni1 and ni2 types. But you now also have an valid instance of the class object in wcserverapi. If I understand brackets, it would be better for me, the human, for readability, if I wanted to do this this way: Dim [wcserverapi] As WcServerAPI Dim ni1 As WcServerAPI.TwcNodeInfo Dim ni2 As WcServerAPI.TwcNodeInfo Would be more "readability" so when I see and use [wcserverapi] I would be referring to the variable, and not the class. Is that correct? -- Mike wrote:
Show quoteHide quote > Armin Zingler wrote: No, readability is not an issue at all when using the brackets. It wouldn't>> Mike wrote: >>> >>> I think I see. So basically, its nothing more than to help one not >>> confuse the mixing of a variable name as keywords or type, i.e. >>> >>> Dim string as STRING < --- compiler error >>> dim [String] as String >>> Dim [random] As New Random(2000) >> >> Random is not a keyword, therefore >> >> Dim random As New Random(2000) >> >> works also. >> >>> >>> or >>> >>> Dim myClass As MyClass >>> >>> which compiles, >> >> Does not compile here because myClass is a keyword. > > hmmm, then I don't yet understand. I said that because I tried this: > > imports Wildcat.Net.Server > > ... > Dim wcserverapi As WcServerAPI > Dim ni1 As WcServerAPI.TwcNodeInfo > Dim ni2 As [WcServerAPI].TwcNodeInfo > > WcServerAPI is a class in my wildcat.net.server.dll > > It all compiled. I understand the compiler (the compiler knows <g>) is > using the CLASS WcServerAPI for ni1 and ni2 types. But you now also > have an valid instance of the class object in wcserverapi. > > If I understand brackets, it would be better for me, the human, for > readability, if I wanted to do this this way: > > Dim [wcserverapi] As WcServerAPI > Dim ni1 As WcServerAPI.TwcNodeInfo > Dim ni2 As WcServerAPI.TwcNodeInfo > > Would be more "readability" so when I see and use [wcserverapi] I > would be referring to the variable, and not the class. > > Is that correct? help anyway, because it is not possible to distinguish between the variable name and the class name by using brackets or not. This compiles w/o a problem: Dim Form1 As Form1 Form1 = New Form1 Form1 = New [Form1] [Form1] = New Form1 [Form1] = New [Form1] The brackets don't matter. In addition, you could combine the 4 assignments with any of these declarations: Dim Form1 As Form1 Dim Form1 As [Form1] Dim [Form1] As Form1 Dim [Form1] As [Form1] Everything works because everything the brackets do is: not hurt. ;) The _only_ reason to use them is to use a keyword as an identifier, be it a class name or a variable name. You can even reduce these cases by those that are unambigous for the compiler: Public Class Form1 Public [String] As String Private Sub Test Me.String = "abc" 'works! End Sub End Class It works because there is never a keyword after the dot. BTW, what do you think is the name of the field? Is it "[String]" or is it "String"? I've looked at the IL code and it says: .field public string String So, the brackets are _only_ there for the compiler to be able to distinguish between an identifier and a keyword in it's first, lexical, compilation pass. The brackets don't belong to the identifier itself, i.e. they are removed. Armin "Armin Zingler" <az.nospam@freenet.de> schrieb: One exception to this rule: A type's name is the same as one of the > The _only_ reason to use them is to use a keyword as an identifier, be it > a > class name or a variable name. 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 /// -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://dotnet.mvps.org/dotnet/faqs/> Herfried K. Wagner [MVP] wrote:
Show quoteHide quote > "Armin Zingler" <az.nospam@freenet.de> schrieb: True, but I don't see the exception to the rule. With the first declaration>> 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 > /// you want to use the keyword as an identifier. This _is_ the rule that you quoted. Armin "Armin Zingler" <az.nospam@freenet.de> schrieb: Sorry, I misunderstood what you have written.> 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. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://dotnet.mvps.org/dotnet/faqs/> 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 Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%235ljVEN3JHA.3304@TK2MSFTNGP06.phx.gbl... > "Armin Zingler" <az.nospam@freenet.de> schrieb: >> 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 > /// > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://dotnet.mvps.org/dotnet/faqs/> Herfried K. Wagner [MVP] wrote:
Show quoteHide quote > "Armin Zingler" <az.nospam@freenet.de> schrieb: This is my 3rd post, that wasn't posted.. hope it takes now.>> 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 > /// 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,
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 Show quoteHide quote "Mike" <unkn***@unknown.tv> wrote in message news:OEMpvQP3JHA.1512@TK2MSFTNGP05.phx.gbl... > Herfried K. Wagner [MVP] wrote: >> "Armin Zingler" <az.nospam@freenet.de> schrieb: >>> 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] wrote:
> Mike, First, you seem to be a combative person so I hope by me continuing to > > 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 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. -- Show quoteHide quote> "Mike" <unkn***@unknown.tv> wrote in message > news:OEMpvQP3JHA.1512@TK2MSFTNGP05.phx.gbl... >> Herfried K. Wagner [MVP] wrote: >>> "Armin Zingler" <az.nospam@freenet.de> schrieb: >>>> 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,
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 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. Cor Ligthert[MVP] wrote: Show quoteHide quote > 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 wrote:
> The main reason in my original question was if there was a *technical You have to use square brackets around Enum in the following line:> 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. Dim dataFiles([Enum].GetValues(GetType(Info.Stuff.Things)).Length - 1) As String as without them it expects an expression. Andrew Andrew Morton wrote:
Show quoteHide quote > Mike wrote: Ok, thanks for sharing this.>> 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 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 wrote:
> Finally, I think, as Armin suggested, its a "compiler thing" <g> Why Sorry, I meant "a DIRECT reference to the ......"> [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? :-) -- Mike wrote:
Show quoteHide quote > Mike wrote: You are using the _keyword_ Enum because you do not use [Enum]. The keyword> >> 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 ......" 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 wrote:
Show quoteHide quote > Mike wrote: I wasn't trying to change the semantics. The point is that there is >> 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. 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 wrote:
Show quoteHide quote > Armin Zingler wrote: "to use it here". That's what I consider a "context". You wrote:>> Mike wrote: >>> 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. >>>> What other possible translation could that be but a direct This indicates that you expect a context specific behavior.>>>> reference to the ENUM class shared static methods? > [ENUM] is telling the compiler to access You mean _without_? Yes, because Array is not a keyword.> 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 I fail to see the point here.> object you are working with. > > If the IL shows that this created a local anonymous instance, then > using [ENUM] is more efficient. Armin Armin Zingler wrote:
>> Overall, [ENUM].method is not required. Just reference the enumerated My original quest was to find out if there was a some technical reason >> 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. 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 wrote:
Show quoteHide quote > Andrew Morton wrote: That works too. Hey, all I thought you wanted was an example of where square >> 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 brackets are required :-) > What am I missing? Is it more optimal, more efficient, abeit maybe Perhaps it's a style thing to keep it aligned with the idea of accessing a > 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. 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 wrote:
> That works too. Hey, all I thought you wanted was an example of where square But it wasn't technically required. :)> brackets are required :-) >> What am I missing? Is it more optimal, more efficient, abeit maybe Right, its what makes it easier for the developer to understand.>> 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. 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. -- Andrew Morton wrote:
<snip> > You have to use square brackets around Enum in the following line: Notice that each element in the program text is first "tokenized"> > Dim dataFiles([Enum].GetValues(GetType(Info.Stuff.Things)).Length - 1) As > String > > as without them it expects an expression. 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. 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. :-) CorShow quoteHide quote "Mike" <unkn***@unknown.tv> wrote in message news:u52eLmf3JHA.480@TK2MSFTNGP06.phx.gbl... > 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. > > > Cor Ligthert[MVP] wrote: >> 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 
Other interesting topics
use variable as textbox name?
treeview in windowsdialog Call button click event Using function with PChar data type Visual Studio 2008 and Classes Inheriting From System.Web.UI.WebControls.Style Problem with embedded carriage returns trouble reading word documents Good tutorial for working with XML still problems reading word documents... Build Number - how to auto increment? |
|||||||||||||||||||||||
