|
PureBytes Links
Trading Reference Links
|
I like the idea of being able to declare variables such as:
GlobalStatic myStaticVariable;
SharedStatic mySharedVariable;
We already have the Shared Static of course through the Static
functions. However, we end up having to append some key to the name
in order to be able to use the same static variable in the same AFL
used on more than one chart. This does actually add a level of
complexity in AFL programs and a source of errors for support to sort
out.
The concept of having a static variable that is not shared with other
AFLs would IMHO add a simplification to AFL programming worth
consideration.
Best regards,
Dennis
On Nov 6, 2009, at 1:00 PM, Tomasz Janeczko wrote:
> I agree that Mike's comments were quite good.
> The only difference in opinion is that I would call use "public
> static" everywhere
> instead of two different "global static" and "public static". In AFL
> there is no need to differentiate declaration vs definition.
> Less confusion and less error prone. Still I like simplicity and
> quickness of "shared" (or maybe "public" alone?)
>
> What I don't like with this approach is that having such simple
> keyword will make it way too easy for people
> to declare everything as public and then cry to support that they
> run out of memory.
>
> The original poster as well as others simply forgot the key
> difference between AFL and other languages.
> The fact that simple variable in AFL can be ARRAY and in extreme
> cases such array can have megabyte size.
> Encouraging abuse of static/shared variables by making it too simple
> and no-brainer, would result in
> people complaining that they run out of memory.
> Try using hundreds of things like
> static float x[ 10000000 ];
> in C/C++ and you will see what I mean.
> There is really huge difference between having 100 static numbers
> (scalars) and 100 static arrays.
> That was also one of the reasons why initially static arrays were
> not available in AB.
> As soon as I implemented it, I have seen people coming to support
> with complaints that
> they have created zillions of static arrays and they have problems
> (out of mem).
>
> If these keywords were implemented, there would be strong need to
> build in safety measures to protect
> AmiBroker from abusing such functionality by using 100s of array
> static vars.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "progster01" <progster@xxxxxxxxxxxxxxxxxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Friday, November 06, 2009 6:37 PM
> Subject: [amibroker] Re: Biggest shortcoming of AFL scripting language
>
>
>> 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 amibroker@xxxxxxxxxxxxxxx, "Mike" <sfclimbers@xxx> 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
>>>
>>
>>
>>
>>
>> ------------------------------------
>>
>> **** 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
>
>
>
------------------------------------
**** 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/
|