"But if I were the developer of AFL, it would really bother me and I would fix it so that AFL were easier to read and code."
I'm sure if you were the developer, you would quickly change your mind. The man would have a million conflicting priorities. While this feature you are discussing I would classify as a "nice to have" there are no doubt many many other things pressing on his time. I think he does an incredible job in producing a stable reliable global software product at a competitive price. Mark 2009/11/6 scourt2000 <[email protected]> > > > > > Tomasz, > > First off, if we're talking about programming languages in-the-large, I > have no earthly idea why you ever decided that global variables in a script > should not be remembered between runs of that script. It was your decision > as a language designer to diverge from standard implementation practices and > *that* is the root cause of confusion if we're going to compare mature, > widespread programming languages with AFL. > > That being said, I will give you a perfect example of what I'm talking > about in reality with another well-known charting package as it compares to > AFL and there is absolutely no confusion involved. > > We all know that eSignal uses Javascript for its chart scripting language. > In eSignal's usage of Javascript (aka EFS), global variables are, well, > global variables. They retain their values through multiple runs of a script > in a chart. They are global to the script and also private to that > particular script. So, global variables are not shared among different > scripts in the same chart or different charts. > > But, how did eSignal allow variables to be shared between different > Javascript (EFS) scripts? Simple...in THE SAME WAY Amibroker does it. > > They created 2 functions: setGlobalValue(name, variable) and > getGlobalValue(name) or, in example form: > > In chart #1, running script A: > > var a = 10; // some global variable in script A > setGlobalValue("a", a); // set private global 'a' to a shared global 'a'. > note: the global shared "a" could be any name I wanted it to be > > In chart #2, running script B: > > var b = 0; // some global variable in script B > > b = getGlobalValue("a"); // retrieve shared global 'a' and place in private > global 'b' > > Gee, where's the confusion? There is none. Because you use a function to > get and set global shared variables while normal global variables are > "global private" (and remembered between runs) in their respective scripts. > > Was deciding NOT to have global variables in AFL, in the first place, NOT > be remembered between runs of an AFL script a languauge design flaw? The > answer is YES! The eSignal example proves that because temporary global > variables whose values are overwritten between runs of a script do not have > harmful side effects to global variables which don't get overwritten between > runs of that same script. The example also showed how eSignal has > implemented Amibroker's usage of setting global shared variables between > scripts. > > By the way, I told everyone in my first post what the answer would be for > my request..."nothing is broken, use StaticVarSet/Get". > > Note: > > ALL programming languages are flawed. But global variables retaining their > values for the life of their runtime has never been one of them. Tomasz > decided that the phrase "life of their runtime" meant one pass of a script's > execution. He had no choice but to create a set of functions in AFL to > retain global values though multiple script runs. But you should NEVER use > functions to fix language design problems. The only purpose of the > StaticVarSet/Get family of functions should be to share variables between > DIFFERENT scripts, not to provide persistence within the same script. > > I don't know what the ramifications are of changing the semantics of AFL's > global variables to be persistent between separate invocations without > having to do anything else. Tomasz would be the one to give specific > examples of where that would break existing, working code. > > What I do know though, is that if there is a problem with changing the > semantics, it could easily be fixed to not break old code by introducing a > new #pragma statement like: > > #pragma persistentglobals > > This would make everything transparent from the user's perspective. The old > semantics would be retained and the new semantics of using global variables > in a script to mean "global private" would have to be requested by "the > unconfused" among us. ;-) > > There's nothing in this for Tomasz. He doesn't make more money and he could > care less if I have to litter AFL code with umpteen thousand > StaticVarSet/Get functions to solve the problem on "my side" instead of > "his". > > But if I were the developer of AFL, it would really bother me and I would > fix it so that AFL were easier to read and code. > > ...but I'm not...so there you go. > > > --- In [email protected] <amibroker%40yahoogroups.com>, "Tomasz > Janeczko" <gro...@...> wrote: > > > > Hello, > > > > I would not call it "shortcoming" at all. It would be shortcoming if > there was NO static variables, > > but they *are* available. > > Sure you can complain that you need to type few more letters to > read/store static variable, > > but the functionality is there and what you call "shortcoming" is rather > (in)convenience. > > > > As to the suggestion - actually I was thinking about it BUT... there is > one rather important issue: > > > > in contrast to C/C++ where static variables are INVISIBLE to other object > code blocks (non-shared, private variables), > > in AFL static variables are in fact GLOBAL SHARED variables. The only > common thing is than in both C/C++ and AFL > > the static variables "keep" their values as long as program runs. > > > > Implementing what you are suggesting will lead to confusion and > misunderstandings because > > same syntax would have different semantics for C/C++ coders coming to > AFL. > > > > If static keyword was introduced it would need to be private, non-shared. > > For strict equivalence to StaticVarSet/Get one would need to introduce > completely different keyword, > > such as "shared" or "shared static". Otherwise there would be endless > problems with misunderstandings > > of visibility and scope of variables. > > > > Best regards, > > Tomasz Janeczko > > amibroker.com > > ----- Original Message ----- > > From: "scourt2000" <steveh...@...> > > To: <[email protected] <amibroker%40yahoogroups.com>> > > Sent: Thursday, November 05, 2009 9:14 PM > > Subject: [amibroker] Biggest shortcoming of AFL scripting language > > > > > > > > > > AFL needs something like: > > > > > > static { > > > a = 1; > > > b = 2.3; > > > c = "hello world" > > > } > > > > > > The first time the script is read into a chart, the variables within > the static{} clause would be created and initialized. > > > Their values would be GLOBAL and REMEMBERED from run-to-run of the > script. > > > > > > I know what you're thinking.... > > > > > > "Well, you can use StaticVarGet(), StaticVarSet(), StaticVarGetText() > and StaticVarSetText() and do the same thing you're trying > > > to show here so what's your point?". > > > > > > My reaction to that kind of question is...HUH?! > > > > > > Oh, you mean you would rather say: > > > > > > "StaticVarSet("a", 3)" or "a = StaticVarGet("a")" > > > > > > rather than: > > > > > > "a = 3" or "a" > > > > > > to have values set/get and remembered between runs of the script > (global, yet private to that particular script)? > > > > > > Now, tell me honestly, which one makes YOUR programming life easier and > your scripts easier to be read by others? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > **** IMPORTANT PLEASE READ **** > > > This group is for the discussion between users only. > > > This is *NOT* technical support channel. > > > > > > TO GET TECHNICAL SUPPORT send an e-mail directly to > > > SUPPORT {at} amibroker.com > > > > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > > http://www.amibroker.com/feedback/ > > > (submissions sent via other channels won't be considered) > > > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > > http://www.amibroker.com/devlog/ > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > >
