[V4REV] Constants

[Robert Brenstein]

>
>>  So
>>  get VDatabase_Create(dbRef, mPath,4, 32 * 1024,4)  gives 4 files but so
>>  does
>>  get VDatabase_Create(dbRef, mPath,4, 32 * 1024,1)  and so does
>>  get VDatabase_Create(dbRef, mPath,4, 32 * 1024,8)
>>
>>  so numbers don't work. What is the proper syntax for this?
>
>Wait a moment, the number of db files is specified by 3d parameter.
>All your examples have it 4. This is why you get 4 files always.
>
>So if you want change mode of db, you need write
>
>      get VDatabase_Create( dbRef, mPath, 1, 32 * 1024 )
>

Ron, it seems that Ruslan did not answer your immediate problem, so 
let me pop in. The number you pass as the parameter to 
database_create does NOT correspond to the number of files. It is 
just a numerical value of one of those literal constants.

Each literal/value corresponds to a different combination of the 
number of physical files and what data/info is in each of those files.

I think an explanation like this should be added to this function's 
description in V4REV doc even though it is somewhere in the Kernel 
doc. And the description of the inEnumMode parameter should be 
corrected. It is wrong. In V1, this parameter was refered to as 
fileMode, so may be Ruslan should change it in V2 to inFileMode.

This is actually a general comment: parameter names should refer to 
their content not enum names. Enums they belong to should be provided 
separately. Names of things in Transcript should be self-descriptive 
or self-defining. Carrying them over literally from RB makes them 
feel so foreign to Rev users.

inEnumMode = kDsc_Dat_Blb_Ind

How in the helll, am I supposed to know that the above means to look 
for list of possible constants in EVDbMode enum?

It should be at least like

inDbFileMode = EVDbMode.kDsc_Dat_Blb_Ind

or something like

inDbFileMode EVDbMode [=kDsc_Dat_Blb_Ind]

which makes the parameter name descriptive, gives the enum it belongs 
to, and defines the default value.

Similarly

inStrValue string [=empty]

here using the native Transcript type instead of enum.


>Next, I am not sure that we it is good idea to allow numeric values of
>constant at all !!!!!!!!!
>
>In the next letter I will again describe how we going to make constants for
>next build.

This is indeed a dilemna and I haven't convinced myself which is better:

-- only literal constants
-- only numeric constants
-- either literal or numeric

A big plus for using literal constants, and this is why they are used 
in other languages, is that they let Ruslan and his team to change 
their values without breaking our code. They are also more mnemonic, 
so stick in memory easier and give visual feedback as to what value 
they represent. But then, we have to face constructs like "fIndexed + 
fUnique" (may be we should think if it is possible to avoid these by 
passing multiple flags as independent parameters -- the flag 
parameters would have to become position independent and using 
numeric constants would not be possible).

Robert