[V4REV] Constants

[ron barber]

Hi Robert,

Thanks for joining in,

On Jun 20, 2005, at 5:53 PM, Robert Brenstein wrote:

>>

> 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.

As you can see, the mistake was mine, I had the parameters in the wrong 
order. I was clear that the number does not correspond to the number of 
files. (Note that I tried it with 8!)

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

right.

>
> 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.

absolutely agreed.

> 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.

I still am unclear about this notation. It has taken me a little time 
to understand the difference between these two styles:

EVDbMode    kDscDatBlbInd  = 1   kDsc_DatBlbInd   = 2   kDsc_DatBlb_Ind 
  = 3   kDsc_Dat_Blb_Ind  = 4   kDscDatBlb_Ind  = 5   kDscDat_Blb_Ind  = 
6   kDscDatInd_Blb  = 7   kDsc_DatInd_Blb  = 8

EVFlag   fNone      = 0   fNullable     = 1   fIndexed     = 2   
fUnique     = 4   fIndexByWords   = 8   fCompressed    = 32   fMethod   
   = 64

Those that begin with f can be combined "fIndexed fUnique" as one 
parameter whereas those with k are one single constant. So obvious and 
yet so foreign to my narrow xtalk world and small brain ; )

>
>
>> 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).

Ruslan just said that they will not allow numeric constants and I can 
agree to that if the names are more consistent. If there is a choice 
between:

1.  "fIndexed + fUnique"

flags as one parameter enclosed in quotes (and Ruslan said that a space 
or comma could be used as well as the plus sign) and

2. position independent flags

then I choose 1.

So what do you think of:

1. Consistent parameter positions
2. literal constants enclosed in quotes
3. multiple flags separated by space or comma or plus
4. no numerics

thanks
Ron