Permission and scope are the same thing. If you can't see it (i.e. out of scope), you can't use it. If you can see it (i.e. in scope), you can use it.
Otherwise I agree. The existing functionality is very powerful, particularly when used in combination with dynamic variables. My comments were somewhat tangental to the original post in that I was mostly building off the request in favor of the concept of a globaly available immutable value, which in java is declared as "public static final". Though, admittedly, that could just as easily be achieved via "const" or "#define" and need not be persisted between runs at all. Mike --- In [email protected], "paultsho" <paul.t...@...> wrote: > > > > > If Tomasz was designing a new language, then this discussion might have been > fruitful. And I might even support one of the well thought suggestions. But > the simplifications suggested by scourt2000, modified by Mike and supported > by progster provide a very complex picture that frankly are a lot more > confusing and less functional than the 2 two functions StaticVarSet and > StaticVarGet. > Let me explain what i mean. The declaration static in C++ and other language > of the same genre (java included) has two properties. First is Scope, Second > is persistance. In terms of scope, it is within either the function, the > class or file scope that it is declared. Outside of that it simply doesnt > exist. The Second property is persistance. static tells the compiler that the > variable/class member still holds its value even if controll is passed out of > scope. So the value persist next time when control is in scope again. Now > Mike's suggestion is about permission, which is third dimension and isnt a > property of static. It specify who/what has permission to acesss the > variable's value but it doesnt say anything about scope or persistence. To > cater for all of these, then you must have something like this: > Global public static xyz; > Not only that, Global by default should not have anything bigger than a file > scope. So we need to define xyz as > Extern Global public static xyz if we want to access it from another file. > Now you might say you can simply it by excluding mutually exclusive > combinations. But That is where what we'll have to begin with. > AFL is a script language, it is not object oriented and there is no instance > that anything can be private to deny unauthorised access. > The original suggestions was ambiguous, the additional suggestion doesnt > really clarify that, but it does create another way to make it more complex, > And to make Mike and Scout's approach unambiguous we need to go the extent of > Extern Global public static..... and perhaps more. > On the other hand, StaticVarGet is a function which allow us to bypass these > problems. It also has two additional advantages > 1. The argument, hence the variable in question, can be gotten through string > concatenations programatically. > 2. The function can be accessed through dll - a big plus for portability and > versatility. > My conclusion is that StaticVarGet is still superior and easier to understand > than what were being suggested. > /Paul. > --- In [email protected], "progster01" <progster@> wrote: > > > > Mike, > > > > Very thoughtful commentary you've made, there's alot to agree with there > > (even for those coming from C++ rather than Java). > > > > IMO, all the types of locality specifiers have their uses. Having a few > > more of them at our disposal would be great (carefully chosen by TJ to > > integrate well, of course!). > > > > - Progster > > > > > > --- In [email protected], "Mike" <sfclimbers@> wrote: > > > > > > I'd like to address what I see as a flaw in the logic of the original > > > post, as well as a suggestion to Tomasz's reply. > > > > > > There are perhaps more Java developers now than C++ developers. For the > > > true equivalent of StaticVarGet/Set, the Java keyword "public" would work > > > very nicely (as opposed to "shared"). > > > > > > e.g. Java > > > > > > class MyClass { > > > public static int a; > > > ... > > > } > > > > > > e.g. AFL > > > > > > public static a; > > > > > > In Java, the variable "a" would be accessible as is (i.e. just by typing > > > "a") anywhere within its own class definition (i.e. the file), and in > > > qualified form outside of its class (e.g. MyClass.a). > > > > > > As Tomasz pointed out, the AFL declaration would be global and therefore > > > have no equivalent qualifier (i.e. no MyClass qualifier). I believe that > > > that is what would be the biggest source of confusion with what the > > > original poster suggested. > > > > > > Consider that: > > > > > > - In Java, when we write MyClass.a from within MyOtherClass, it is clear > > > that the static variable is coming from somewhere else (i.e. from the > > > file MyClass.java). > > > > > > - Similarly, using AFL's function call StaticVarGet, in a different file, > > > makes it clear that the variable is not necessarily local to the current > > > file. > > > > > > Compare the above to the original poster's proposal of just using > > > > > > "a = 3" or "a" > > > > > > When "a" is referenced outside of the file that it was declared in, the > > > variable becomes ambiguous. Should it default to a new implicit, non > > > static variable as is the current behavior? Or, should it first try to > > > resolve against a static variable of that name? What happens when the > > > user has set the option to force all variables to be explicitly declared; > > > Must the author redeclare the static in every file that its referenced? > > > Clearly, the proposal as originally suggested is not sufficient. > > > > > > However, this weaknesses might be addressed by requiring the use of the > > > existing "global" keyword whenever a static is to be referenced outside > > > of the file in which it was declared. > > > > > > e.g. > > > > > > File1.afl > > > public static a; // Declared in File1.afl > > > a = 3; > > > > > > File2.afl > > > global static a; // Treat as having been declared somewhere else > > > x = a; > > > > > > This has the advantage of building upon the semantics of the existing > > > "global" keyword, while at the same time being compatible with the > > > requirement of explicit variable declarations. > > > > > > Going a step further, what I would really like to see is the introduction > > > of both "static" and "final" such that we can write our own > > > procedures/functions that accept constants just as AmiBroker itself has > > > constants for atcFlagDefaults, etc. > > > > > > e.g. > > > > > > File1.afl > > > public static final myInterestingValue = 0; > > > public static final myOtherValue = 2; > > > > > > procedure doSomething(value) { > > > switch (value) { > > > case myInterestingValue: ... > > > case myOtherValue: ... > > > } > > > } > > > > > > File2.afl > > > #include_once <File1.afl> > > > ... > > > doSomething(myInterestingValue); > > > > > > > > > We can do this now already. But, we have no way to protect against anyone > > > accidentally changing the value of myInterestingValue, myOtherValue. > > > > > > These two keywords would go a long way towards promoting more modular > > > code in larger coding projects. > > > > > > Mike > > > > > >
