Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #3831 > unrolled thread

Re: Best practice for using constants outside of code?

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Best practice for using constants outside of code? Jongware <jongware@no-spam.plz> - 2011-02-02 15:56 +0100
    Re: Best practice for using constants outside of code? Ikke <ikke@hier.be> - 2011-02-02 15:16 +0000
      Re: Best practice for using constants outside of code? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-02-02 21:29 +0100

#3831 — Re: Best practice for using constants outside of code?

On 02-Feb-11 15:49 PM, Ikke wrote:
> Hi everyone,
>
> I was wondering if there was a best practice on using constants outside
> of your code (as in datafiles, or databases). For example, consider the
> following:
>
> A program handles data on persons, using an integer variable to hold the
> gender of the person. Constants have been defined as follows:
>
> ConstGenderUndefined = 0
> ConstGenderMale = 1
> ConstGenderFemale = 2
>
> In source code, 0, 1 or 2 will never be used - that's obviously the
> reason the constants are there in the first place.
>
> However, the data itself (.ini files, table in a database, whatever) will
> of course hold the values 0/1/2.
>
> Suppose we now change the constants, so that the values for male and
> female are switched - all data now becomes invalid, unless we update it
> to the new constant values.
>
> I've been thinking of a solution for a while, but can't come up with
> anything decent or practical.
>
> Does anybody have any suggestions on how to properly handle this
> situation?

That can only be solved by adding another layer of constant/value 
definitions.
How about a simple .INI file?

[Jw]

[toc] | [next] | [standalone]

#3838

<snip>
> That can only be solved by adding another layer of constant/value 
> definitions.
> How about a simple .INI file?

Thanks for your suggestion!

Unless I incorrectly interpreted your suggestion, that would leave the same 
problem I guess...

The original ini file would be changed from:
person.gender=1
to:
person.gender=ConstGenderMale

The ini file holding the constants would define the constants as:
ConstGenderMale=1

And the constants in code would remain the same:
ConstGenderMale=1

As soon as anybody makes a change in either code or .ini, he/she will need 
to remember to change the counterpart in .ini or code as well, which is 
what I was trying to avoid.

Ikke

[toc] | [prev] | [next] | [standalone]

#3839

Ikke <ikke@hier.be> writes:

> <snip>
>> That can only be solved by adding another layer of constant/value 
>> definitions.
>> How about a simple .INI file?
>
> Thanks for your suggestion!
>
> Unless I incorrectly interpreted your suggestion, that would leave the same 
> problem I guess...
>
> The original ini file would be changed from:
> person.gender=1
> to:
> person.gender=ConstGenderMale
>
> The ini file holding the constants would define the constants as:
> ConstGenderMale=1
>
> And the constants in code would remain the same:
> ConstGenderMale=1
>
> As soon as anybody makes a change in either code or .ini, he/she will need 
> to remember to change the counterpart in .ini or code as well, which is 
> what I was trying to avoid.

Obviously, you will have to define your constants differently:

const
   ConstGenderMale = "ConstGenderMale";
   ConstGenderFemale = "ConstGenderFemale";


Then of course, since you will have to provide functions to read and
write these representations and convert them into these constant values,
you might want to define a class:

class: Symbol
   slots:
       name: String;
       value: String;

function keyword(name)
   new Symbol name=name value=name

function read:
   token := parseToken();
   if token.type = identifier then
      return keyword(identifier)
   else
      ...

method print (self Symbol)
   write(self.value)



So you can define:

const
  ConstGenderMale   = keyword("ConstGenderMale");
  ConstGenderFemale = keyword("ConstGenderFemale");



Of course instead of apply Greenspun's Tenth Law all the time, you could
also just use Lisp.
  
-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web