|
PureBytes Links
Trading Reference Links
|
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
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> 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" <stevehite@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> 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
> >
> >
> >
>
------------------------------------
**** 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
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
amibroker-digest@xxxxxxxxxxxxxxx
amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|