Leaderboard

Yes exactly the points I was going to raise as well, thanks ShauR. I would also add that essentially what you're saying is: byref is inherently "better" than byval and this is one situation that you have put forward to illustrate that point. I disagree on the priority given by many to byref esp in the LV environment and that for a number of reasons. The most important is that by val is the native "core" of LVOOP and there are a number of reasons for that are best explained, if I remember correctly, in a series of notes by AQ and perhaps the white paper as well -- for those who are interested in pursuing that. Having used FGVs for now almost 12 years, I find them a very robust way to implement, as ShaunR indicates, objects and not so much singletons, although that has become the default case for many. For years that was just about the only way to do that or anything like it that in LV. And, yes "god functions" are a problem, uh perhaps I should say, however they are instantiated. Being a class doesn't guarantee lack of god elevation. If on the other hand you want to "cast" FGVs as CBR substitutes then, yes, you'll create some interesting entanglements. But doesn't that get back to the issue (at least potentially) of prioritization of byref constructs? So as is the case with many LV constructs, if you don't like them, then don't use them. Just bear in mind that it isn't accurate to say that they are inherently dangerous or especially prone to idol worship.....

John, I'm glad that you are questioning this methodology. First I would strongly recommend that you review this well written Field Architect blog about this very topic. There are many many skilled LV developers that have either based their entire architecture on this tactic or used it as a staple of their programs. These are actively running programs, and I would say there is no doubt as to the validity of this approach. However! There are many drawbacks and caveats and I truly believe that this practice of coding represents a style which in the future we'll look back like we look back at finger paintings from grade school (cute, simplistic and far from a desirable design) Personally speaking, I was bitten VERY recently when another developer used LV2 style globals and never took into consideration the idea of needing two of the same thing. What ended up happening when another of the same thing was needed, was that a developer just copied 'all VI' and appended a '2' to the end of the file names so that he could have 2 of the same thing. If chills didn't just run down your spine....you may want to think about that implication in a very large application. I'll avoid putting all my comments from the blog into this reply, but long story short, there are emerging ideas/techniques/frameworks that will help you accomplish your large application with a much more Scaleable, Modular, Reuseable, Extensible and Simple (SMoRES) . If you have the chance to start a design from scratch and don't need to inherit someone else's choices, I would highly recommend taking this chance to implement a LV2-Global free design and move to LV 2011 instead of '2'