Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. The new GOTO Statement?

The new GOTO Statement?

Scheduled Pinned Locked Moved The Lounge
questionlinqhardwarealgorithmscollaboration
82 Posts 29 Posters 52 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Steve 2

    I don't think it was made just for LINQ, that's not what I've read in countless introdution texts about new features back then. What do you mean by "Except that generics cme later" ? Generics are there since .NET 2.0, var since 3.5 IIRC.

    P Offline
    P Offline
    PIEBALDconsult
    wrote on last edited by
    #64

    Steve#2 wrote:

    not what I've read in countless introdution texts

    Which were likely written by they who abuse it.

    Steve#2 wrote:

    What do you mean by

    Generics came after the using directive.

    1 Reply Last reply
    0
    • OriginalGriffO OriginalGriff

      Yes, I agree. Every element of a language has it's use - even goto and var in C#- it's just that if you use them inappropriately you get less readable code instead of more. Personally, I find lambdas are useful in their place, but I avoid using them most of the time. var should be banned outside Linq!

      Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

      I Offline
      I Offline
      Ian Shlasko
      wrote on last edited by
      #65

      Nah, var has its uses... I basically use it in two situations: 1) Triggering simple events, just because it's glue code that I don't care about:

      private void OnDownloaded()
      {
      var evt = DataDownloaded;
      if (evt != null)
      evt(this, EventArgs.Empty);
      }

      1. Eliminate long, redundant declarations, when there's nothing fancy going on... I know, some people would rather see the type on the left side, but I happen to find this a LOT more readable:

      var modelTemp = new ViewModels.GridTree.ViewTableModel(view);

      I actually don't use it for LINQ unless the generated types are really nasty... LINQ types aren't "obvious", so I'd rather see exactly what they are... And if the returned type is a Lookup of Dictionaries of HashSets of Arrays of Strings, then that's a signal to refactor, not a reason to use var. Just eearched my code and found 79 uses of the var keyword... Except it looks like about 75% of them are in my snippet-generated OnPropertyChanged functions (INPC in models)... Another 20% or so are in third-party code, and the rest are more of the two items I listed above. ... Speaking of third-party code... Just glanced at a few of the var hits from one of the controls I scavenged, and found: var stepSize = (int)value;... That's just unnecessary...

      Proud to have finally moved to the A-Ark. Which one are you in?
      Author of the Guardians Saga (Sci-Fi/Fantasy novels)

      F 1 Reply Last reply
      0
      • S sisnaz

        After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.

        K Offline
        K Offline
        Kirk Wood
        wrote on last edited by
        #66

        It all depends on the context. I mean it would be horrible (but possible) to put the entire program crammed down into the main function (method) of your program. It would not be the GOTO, it would be something much more hideous. But if you need to iterate through an IEnumerable and only work with some of them it is quite nice to throw in a lambda expression to do this: foreach(var item in collection.Where(i=>i.Care==true) Another place I have found a great like (though it does have some ramp time to get used to it) is to use a lambda expression for an async method callback. In this case I find it makes it easier to read because: 1) It keeps the whole process together. 2) No need to cram context and then cast it. (Yes I know there is overhead and under the covers everything gets shoved into a context object and pulled back out, but I choose to only worry about noticible performance.) Now I have seen some horrible uses as well that seemed "cool." In the end if it doesn't make it easier to maintain it makes it more fragile.

        1 Reply Last reply
        0
        • K Kevin Marois

          Had a "senior" guy I worked with who asked in a meeting why you couldn't do

          var myvariable = null;

          If it's not broken, fix it until it is

          OriginalGriffO Offline
          OriginalGriffO Offline
          OriginalGriff
          wrote on last edited by
          #67

          :doh: Post it in Coding Horrors! Oh, and check his hair - is it starting to rise in two peaks?

          Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

          "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
          "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt

          1 Reply Last reply
          0
          • P PIEBALDconsult

            Steve#2 wrote:

            type of scenario the "var" keyword was made for.

            Bullpuckey; it was made for Linq. That's exactly the scenario the using directive was made for:

            using MyDic = Dictionary<int, List<Vec3<float>>> ;
            ...
            MyDic stuff = new MyDic() ;

            (Except that generics cme later. :sigh: )

            J Offline
            J Offline
            Jecc
            wrote on last edited by
            #68

            MyDic is a lousy name. It should be

            using DictionaryFromIntToListOfVectorsOfThreeFloats = Dictionary<int, List<Vec3<float>>> ;
            ...
            DictionaryFromIntToListOfVectorsOfThreeFloats intsTo3DFloatCoords = new DictionaryFromIntToListOfVectorsOfThreeFloats() ;

            Edit: 'stuff' is a lousy name too.

            P 1 Reply Last reply
            0
            • S Steve 2

              I think I do: automatic type inference. Which is what my example used them for.

              P Offline
              P Offline
              PIEBALDconsult
              wrote on last edited by
              #69

              No, it's "automatic type inference for those times when the developer can't know the type when writing the code".

              S 1 Reply Last reply
              0
              • J Jecc

                MyDic is a lousy name. It should be

                using DictionaryFromIntToListOfVectorsOfThreeFloats = Dictionary<int, List<Vec3<float>>> ;
                ...
                DictionaryFromIntToListOfVectorsOfThreeFloats intsTo3DFloatCoords = new DictionaryFromIntToListOfVectorsOfThreeFloats() ;

                Edit: 'stuff' is a lousy name too.

                P Offline
                P Offline
                PIEBALDconsult
                wrote on last edited by
                #70

                Jecc wrote:

                MyDic is a lousy name

                What's in a name? It only has scope within the file so keep the file small and easily read.

                1 Reply Last reply
                0
                • P PIEBALDconsult

                  No, it's "automatic type inference for those times when the developer can't know the type when writing the code".

                  S Offline
                  S Offline
                  Steve 2
                  wrote on last edited by
                  #71

                  Well, the numerous examples using it other ways, in the C# 4.0 language spec file, seem to disagree there.

                  1 Reply Last reply
                  0
                  • F Fabio Franco

                    Steve#2 wrote:

                    ince my IDE shows the type of a variable when hovering the cursor over it, which happens to be where I read when scrolling.

                    So you need to hover over it, don't you?

                    Steve#2 wrote:

                    There are languages which don't have something like LINQ but do have automatic type inference, so a lot of people seem to disagree here what such a feature is good for or isn't.

                    Yep, like javascript, I don't think you want a start a discussion that this is a good feature of javascript....

                    Steve#2 wrote:

                    But yeah, I can see how that can be annoying

                    Yes, very much ;)

                    Steve#2 wrote:

                    I hate it when I can't identify scope by looking at the exact same column

                    I hate that as well X| X|

                    Steve#2 wrote:

                    Huh? Var is not dynamic. Bad example?
                    Exactly *because* the type is known at compile time, I do use var in assignments!

                    You're missing the point. The point is, you should use a tool for what it's designed for, not to make your life easy at some point, you gotta think of the consequences.

                    Steve#2 wrote:

                    If something turns out to work quite nicely for something else than original intention, why not use it?

                    That's my point. Using var just because is easier shouldn't be justification at the cost of readability and comprehension. I'm sick of so many times having to look what the type is because I can't deduce it by it's declaration. So, it may work quite nicely for you who does not have to maintain other people's code, but no, it does not work when you do have to.

                    Steve#2 wrote:

                    I have not seen an example of this var use busting something open, other than you personally can't read the code as quickly.

                    You missing the point again, it was just an analogy. And if you haven't seen it, it does not mean it doesn't happen. And it's not just me who can't read as quickly. If you tell me that there is a quicker way to know a variable type other than it's declaration, please enlighten me and the rest of the world.

                    Steve#2 wrote:

                    I don't like just trust, I like compelling explanations.

                    As do I. And that's what I'm doing here in the la

                    S Offline
                    S Offline
                    Steve 2
                    wrote on last edited by
                    #72

                    Well, to make it a bit shorter here, I'll certainly have some thoughts about the severity of readability by slower type deduction. I've haven't heard complaints of colleagues so far, but let's see when asking them directly about it. Though, that the purpose of the var keyword, as intended by the language designers, is solely for anonymous types - I have to agree even less now, seeing how common place it is in examples in the language specification document. Not only should they have refrained from such examples if they didn't intend for it being used such ways, but actually they could easily have restricted the use of the var keyword for ananoymous types (you suggested a warning there). If it's so glarinlgy obvious how "bad" this is, I think they otherwise careful language designers would have seen it themselves. As fiercely as some people here claim that anon types is the "actual only intention" for this - it now seems even more like pure opinion and taste. Just like curly braces position... which people fight as fiercely over, heh.

                    F 1 Reply Last reply
                    0
                    • S Steve 2

                      Well, to make it a bit shorter here, I'll certainly have some thoughts about the severity of readability by slower type deduction. I've haven't heard complaints of colleagues so far, but let's see when asking them directly about it. Though, that the purpose of the var keyword, as intended by the language designers, is solely for anonymous types - I have to agree even less now, seeing how common place it is in examples in the language specification document. Not only should they have refrained from such examples if they didn't intend for it being used such ways, but actually they could easily have restricted the use of the var keyword for ananoymous types (you suggested a warning there). If it's so glarinlgy obvious how "bad" this is, I think they otherwise careful language designers would have seen it themselves. As fiercely as some people here claim that anon types is the "actual only intention" for this - it now seems even more like pure opinion and taste. Just like curly braces position... which people fight as fiercely over, heh.

                      F Offline
                      F Offline
                      Fabio Franco
                      wrote on last edited by
                      #73

                      Steve#2 wrote:

                      Though, that the purpose of the var keyword, as intended by the language designers, is solely for anonymous types - I have to agree even less now, seeing how common place it is in examples in the language specification document.

                      This is debatable. The documentation might have been written by the same as designed. The use of

                      var

                      could've been used for the sake of shortness of documentation and to focus on the main subject of the excerpt.

                      Steve#2 wrote:

                      If it's so glarinlgy obvious how "bad" this is, I think they otherwise careful language designers would have seen it themselves.

                      Well, we have a whole Code Horrors section on code project because language designers cannot prevent bad use of a language. Not saying that

                      var

                      in your example is a horror.

                      Steve#2 wrote:

                      As fiercely as some people here claim that anon types is the "actual only intention" for this - it now seems even more like pure opinion and taste.
                       
                      Just like curly braces position... which people fight as fiercely over, heh.

                      Maybe you're right, but the purpose they were created for are the anonymous types. Maybe they thought along the way, oh this might be useful "for this thing here" too! The var usage can come to opinion and taste at some point, but I still think that readability should be improved when possible, instead of just using var because it's easier. Oh, the curly braces... That's a never ending war.

                      To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                      S 1 Reply Last reply
                      0
                      • F Fabio Franco

                        Steve#2 wrote:

                        Though, that the purpose of the var keyword, as intended by the language designers, is solely for anonymous types - I have to agree even less now, seeing how common place it is in examples in the language specification document.

                        This is debatable. The documentation might have been written by the same as designed. The use of

                        var

                        could've been used for the sake of shortness of documentation and to focus on the main subject of the excerpt.

                        Steve#2 wrote:

                        If it's so glarinlgy obvious how "bad" this is, I think they otherwise careful language designers would have seen it themselves.

                        Well, we have a whole Code Horrors section on code project because language designers cannot prevent bad use of a language. Not saying that

                        var

                        in your example is a horror.

                        Steve#2 wrote:

                        As fiercely as some people here claim that anon types is the "actual only intention" for this - it now seems even more like pure opinion and taste.
                         
                        Just like curly braces position... which people fight as fiercely over, heh.

                        Maybe you're right, but the purpose they were created for are the anonymous types. Maybe they thought along the way, oh this might be useful "for this thing here" too! The var usage can come to opinion and taste at some point, but I still think that readability should be improved when possible, instead of just using var because it's easier. Oh, the curly braces... That's a never ending war.

                        To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                        S Offline
                        S Offline
                        Steve 2
                        wrote on last edited by
                        #74

                        Fabio Franco wrote:

                        Well, we have a whole Code Horrors section on code project because language designers cannot prevent bad use of a language.

                        Yeah I know that language design, or the design of anything for that matter, will not yield perfect and guarandteed fool-proof concepts just when something new is introduced. Still I have the impression that the C# team knows what they're doing (although some people complain about this or that, or that new things like functional langue concepts are included... :-D ) I found this MSDN page: http://msdn.microsoft.com/en-us/library/bb384061.aspx[^] containing the section: _"The var keyword can also be useful when the specific type of the variable is tedious to type on the keyboard, or is obvious, or does not add to the readability of the code. One example where var is helpful in this manner is with nested generic types such as those used with group operations. In the following query, the type of the query variable is

                        IEnumerable>

                        . As long as you and others who must maintain your code understand this, there is no problem with using implicit typing for convenience and brevity."_ So, while they do hint at this usage could be a disadvantage for maintenance, they agree that it doesn't have to - if it's no problem for anyone in the team. Still, if there may other members being added to the team some point later, this may change, and the guy may have a little harder start ^^ While it'd be crazy to try to guard against anything that may or may not happen in the future, and should do what works best for the current team, I think, I now do get the feeling that perhaps it's not too bad an idea to not go too crazy with the var thing. But it's quite interesting, any way. I guess I'll examine some of my code and see how I'm really using it heh :-D And whether the types may be obvious, e.g. because say, in a function that takes a few "decimal" parameters, and only calculates some stuff with decimal all the time, it should not be too hard to figure that all the var stuff in between would be decimal, too. I think this is actually the main occurence of my "var", besides queries of course (which I mostly use for non-database stuff because, laziness can be good :-D )

                        F 1 Reply Last reply
                        0
                        • S Steve 2

                          Fabio Franco wrote:

                          Well, we have a whole Code Horrors section on code project because language designers cannot prevent bad use of a language.

                          Yeah I know that language design, or the design of anything for that matter, will not yield perfect and guarandteed fool-proof concepts just when something new is introduced. Still I have the impression that the C# team knows what they're doing (although some people complain about this or that, or that new things like functional langue concepts are included... :-D ) I found this MSDN page: http://msdn.microsoft.com/en-us/library/bb384061.aspx[^] containing the section: _"The var keyword can also be useful when the specific type of the variable is tedious to type on the keyboard, or is obvious, or does not add to the readability of the code. One example where var is helpful in this manner is with nested generic types such as those used with group operations. In the following query, the type of the query variable is

                          IEnumerable>

                          . As long as you and others who must maintain your code understand this, there is no problem with using implicit typing for convenience and brevity."_ So, while they do hint at this usage could be a disadvantage for maintenance, they agree that it doesn't have to - if it's no problem for anyone in the team. Still, if there may other members being added to the team some point later, this may change, and the guy may have a little harder start ^^ While it'd be crazy to try to guard against anything that may or may not happen in the future, and should do what works best for the current team, I think, I now do get the feeling that perhaps it's not too bad an idea to not go too crazy with the var thing. But it's quite interesting, any way. I guess I'll examine some of my code and see how I'm really using it heh :-D And whether the types may be obvious, e.g. because say, in a function that takes a few "decimal" parameters, and only calculates some stuff with decimal all the time, it should not be too hard to figure that all the var stuff in between would be decimal, too. I think this is actually the main occurence of my "var", besides queries of course (which I mostly use for non-database stuff because, laziness can be good :-D )

                          F Offline
                          F Offline
                          Fabio Franco
                          wrote on last edited by
                          #75

                          Steve#2 wrote:

                          So, while they do hint at this usage could be a disadvantage for maintenance, they agree that it doesn't have to - if it's no problem for anyone in the team.

                          I guess this is the most important aspect to be taken into account, althogh personally, I wouldn't instruct my team to use var for these cases.

                          Steve#2 wrote:

                          While it'd be crazy to try to guard against anything that may or may not happen in the future

                          Yes, but I think it's wise to do our best to do so. A project could be handed to whole different team, or even, a different company. While I don't think using var on the example you mention is the end of the world, it could prove to be a pain in the ass if an entire code base needs to be studied. Imagine the cases where developers act as C# only had the var keyword. :~

                          Steve#2 wrote:

                          laziness can be good :-D )

                          Yes :), specially when it means significant gains in productivity. Related to var, I find it specially true when using Linq to objects that can save a lot of time while querying object collections.

                          To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                          1 Reply Last reply
                          0
                          • I Ian Shlasko

                            Nah, var has its uses... I basically use it in two situations: 1) Triggering simple events, just because it's glue code that I don't care about:

                            private void OnDownloaded()
                            {
                            var evt = DataDownloaded;
                            if (evt != null)
                            evt(this, EventArgs.Empty);
                            }

                            1. Eliminate long, redundant declarations, when there's nothing fancy going on... I know, some people would rather see the type on the left side, but I happen to find this a LOT more readable:

                            var modelTemp = new ViewModels.GridTree.ViewTableModel(view);

                            I actually don't use it for LINQ unless the generated types are really nasty... LINQ types aren't "obvious", so I'd rather see exactly what they are... And if the returned type is a Lookup of Dictionaries of HashSets of Arrays of Strings, then that's a signal to refactor, not a reason to use var. Just eearched my code and found 79 uses of the var keyword... Except it looks like about 75% of them are in my snippet-generated OnPropertyChanged functions (INPC in models)... Another 20% or so are in third-party code, and the rest are more of the two items I listed above. ... Speaking of third-party code... Just glanced at a few of the var hits from one of the controls I scavenged, and found: var stepSize = (int)value;... That's just unnecessary...

                            Proud to have finally moved to the A-Ark. Which one are you in?
                            Author of the Guardians Saga (Sci-Fi/Fantasy novels)

                            F Offline
                            F Offline
                            Fabio Franco
                            wrote on last edited by
                            #76

                            Ian Shlasko wrote:

                            1. Triggering simple events, just because it's glue code that I don't care about:

                            Assigning to var in this case is completely unnecessary, why not check the

                            DataDownloaded

                            directly and avoid a completely unnecessary variable assignment?

                            Ian Shlasko wrote:

                            1. Eliminate long, redundant declarations, when there's nothing fancy going on... I know, some people would rather see the type on the left side, but I happen to find this a LOT more readable:

                            You may find it more readable, but ask anyone else if they can guess what's the return type of your method. :doh:

                            To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                            I 1 Reply Last reply
                            0
                            • F Fabio Franco

                              Ian Shlasko wrote:

                              1. Triggering simple events, just because it's glue code that I don't care about:

                              Assigning to var in this case is completely unnecessary, why not check the

                              DataDownloaded

                              directly and avoid a completely unnecessary variable assignment?

                              Ian Shlasko wrote:

                              1. Eliminate long, redundant declarations, when there's nothing fancy going on... I know, some people would rather see the type on the left side, but I happen to find this a LOT more readable:

                              You may find it more readable, but ask anyone else if they can guess what's the return type of your method. :doh:

                              To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                              I Offline
                              I Offline
                              Ian Shlasko
                              wrote on last edited by
                              #77

                              Fabio Franco wrote:

                              Assigning to var in this case is completely unnecessary, why not check the

                              DataDownloaded

                              directly and avoid a completely unnecessary variable assignment?

                              Simple... Multithreaded system... What if, right after checking if the event is null, the last handler unhooks from it on another thread? As I understand it, the temporary variable avoids that issue.

                              Fabio Franco wrote:

                              You may find it more readable, but ask anyone else if they can guess what's the return type of your method.

                              No, I said redundant... Like

                              List, Something>> blah = new [same thing]();

                              Proud to have finally moved to the A-Ark. Which one are you in?
                              Author of the Guardians Saga (Sci-Fi/Fantasy novels)

                              F 1 Reply Last reply
                              0
                              • I Ian Shlasko

                                Fabio Franco wrote:

                                Assigning to var in this case is completely unnecessary, why not check the

                                DataDownloaded

                                directly and avoid a completely unnecessary variable assignment?

                                Simple... Multithreaded system... What if, right after checking if the event is null, the last handler unhooks from it on another thread? As I understand it, the temporary variable avoids that issue.

                                Fabio Franco wrote:

                                You may find it more readable, but ask anyone else if they can guess what's the return type of your method.

                                No, I said redundant... Like

                                List, Something>> blah = new [same thing]();

                                Proud to have finally moved to the A-Ark. Which one are you in?
                                Author of the Guardians Saga (Sci-Fi/Fantasy novels)

                                F Offline
                                F Offline
                                Fabio Franco
                                wrote on last edited by
                                #78

                                Ian Shlasko wrote:

                                Simple... Multithreaded system... What if, right after checking if the event is null, the last handler unhooks from it on another thread? As I understand it, the temporary variable avoids that issue.

                                Then you're doing it wrong. For multi-threaded applications you should either use lock, semaphore or mutex. Depending on the scenario. This "workaround" could have undesirable results.

                                Ian Shlasko wrote:

                                No, I said redundant...

                                You mean this?

                                var blah = new List, Something>>();

                                To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                                I 1 Reply Last reply
                                0
                                • F Fabio Franco

                                  Ian Shlasko wrote:

                                  Simple... Multithreaded system... What if, right after checking if the event is null, the last handler unhooks from it on another thread? As I understand it, the temporary variable avoids that issue.

                                  Then you're doing it wrong. For multi-threaded applications you should either use lock, semaphore or mutex. Depending on the scenario. This "workaround" could have undesirable results.

                                  Ian Shlasko wrote:

                                  No, I said redundant...

                                  You mean this?

                                  var blah = new List, Something>>();

                                  To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                                  I Offline
                                  I Offline
                                  Ian Shlasko
                                  wrote on last edited by
                                  #79

                                  Fabio Franco wrote:

                                  Then you're doing it wrong. For multi-threaded applications you should either use lock, semaphore or mutex. Depending on the scenario. This "workaround" could have undesirable results.

                                  Ever tried binding a WPF GUI to an INPC class with virtualized ItemsControls? That thing hooks and unhooks the PropertyChanged event so much, I could apply a few X-rated analogies to it :) Just not worth the trouble of locking.

                                  Fabio Franco wrote:

                                  You mean this?

                                  var blah = new List<Dictionary<Tuple<int, string>, Something>>();

                                  Exactly.

                                  Proud to have finally moved to the A-Ark. Which one are you in?
                                  Author of the Guardians Saga (Sci-Fi/Fantasy novels)

                                  F 1 Reply Last reply
                                  0
                                  • I Ian Shlasko

                                    Fabio Franco wrote:

                                    Then you're doing it wrong. For multi-threaded applications you should either use lock, semaphore or mutex. Depending on the scenario. This "workaround" could have undesirable results.

                                    Ever tried binding a WPF GUI to an INPC class with virtualized ItemsControls? That thing hooks and unhooks the PropertyChanged event so much, I could apply a few X-rated analogies to it :) Just not worth the trouble of locking.

                                    Fabio Franco wrote:

                                    You mean this?

                                    var blah = new List<Dictionary<Tuple<int, string>, Something>>();

                                    Exactly.

                                    Proud to have finally moved to the A-Ark. Which one are you in?
                                    Author of the Guardians Saga (Sci-Fi/Fantasy novels)

                                    F Offline
                                    F Offline
                                    Fabio Franco
                                    wrote on last edited by
                                    #80

                                    Ian Shlasko wrote:

                                    Ever tried binding a WPF GUI to an INPC class with virtualized ItemsControls?

                                    Thank God no

                                    To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

                                    1 Reply Last reply
                                    0
                                    • K Kevin Marois

                                      Steve#2 wrote:

                                      And it's exactly that type of scenario the "var" keyword was made for

                                      What "scenerio" is that? You don't want to type more than you have to, so you leave it to the next developer to figure out what the type is?

                                      If it's not broken, fix it until it is

                                      S Offline
                                      S Offline
                                      samuellis
                                      wrote on last edited by
                                      #81

                                      What developer would not know the type of stuff if they saw this?

                                      var stuff = new Dictionary<int, List<Vec3<float>>>();

                                      1 Reply Last reply
                                      0
                                      • S Steve 2

                                        ah, you mean the using ^^ Haven't seen this usage of it, wow, yet another meaning of the keyword "using", I think now that's quite an abuse... (language design wise)

                                        K Offline
                                        K Offline
                                        Keith Badeau
                                        wrote on last edited by
                                        #82

                                        I agree, using was probably a poor choice given it already has a couple of definitions. A typedef would be a better choice, but then again my first languages were C and C++ so I am biased.

                                        1 Reply Last reply
                                        0
                                        Reply
                                        • Reply as topic
                                        Log in to reply
                                        • Oldest to Newest
                                        • Newest to Oldest
                                        • Most Votes


                                        • Login

                                        • Don't have an account? Register

                                        • Login or register to search.
                                        • First post
                                          Last post
                                        0
                                        • Categories
                                        • Recent
                                        • Tags
                                        • Popular
                                        • World
                                        • Users
                                        • Groups