[V4REV] symbolic constants // Based on Assoc Array

[Robert Brenstein]

>  > You seem to be back to defining globals behind our backs :)
>
>This was before I have read you letter
>

I see. I guess I got your responses in wrong order. I have noticed 
that in many instances, the replies to the list arrive before 
original inquiry. I wonder which server changes the order.

>  > Associative arrays are fast, so they won't affect performance.
>
>In fact they always bring some overhead because they act with strings.

I have no worries here. They are as fast as it gets in Transcript. 
Remember that xTalks are string-oriented by definition, so there is 
no slown down for handling strings as it is in other environments. 
And array implementation is really fast.

>  > Please consider seriously to let us decide what the variables are
>>  rather than presetting them for us. Sometimes doing less is better --
>>  more in the spirit of Transcript or xTalks in general. I know this is
>>  contrary to what you do (have to do) for others. But Transcript is
>>  not Lingo or Java.
>>
>  > With this approach, you can at least have the names of actual
>>  constants same as in other environments.
>
>Yes, we will try this way Robert.
>
>Only what I not like -- all constant values are in the same array

I am not sure which part bothers you. Unlike in other environments, 
they constants in rev are mostly for mnemonic/code readibility since 
they are not true enums.

When I switched to MetaCard/Rev, I used to create separate global var 
for each global value I needed. That was the HyperCard way. Then I 
discovered associative arrays. So much easier to handle things like 
preferences or global values. Particularly nice since they couple so 
strongly and well with custom properties. But it is a different frame 
of mind than programming in RB or C/C++, so I can see why it feels 
odd to you.

If you wanted to go all the way, instead of defining constants on our 
side (in our program), you could have Valentina functions accept 
literals instead of, or in addition to, numerical parameters and have 
your external converting these literals into numbers. Then the whole 
issue of val-related globals is out of window. And the constants are 
documented clearly and individually for each Valentina call. This 
would be a proper emulation of enums in Transcript IMHO.

Robert