Path: news.daimi.aau.dk!jlk
From: jlk@daimi.aau.dk (J|rgen Lindskov Knudsen)
Newsgroups: comp.lang.beta
Subject: Re: Global Variables
Date: 9 May 1996 06:45:19 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 98
Message-ID: <4ms49v$bg9@gjallar.daimi.aau.dk>
References: <v7gvii8n7jp.fsf@schroeder>
Reply-To: jlknudsen@daimi.aau.dk (Jorgen Lindskov Knudsen)
NNTP-Posting-Host: lithium.daimi.aau.dk

In <v7gvii8n7jp.fsf@schroeder> Thus spake knaut@schroeder (Claus-Peter Knaut):


>Hello,

>We are developing an Probabilistik Database in BETA. 
>We need global variables. How do you manage to use them. You can not
>place them in lib: attributes because there you can define no static
>objects.

>We manage it by placeing all beta-code in one main.bet. And only
>main.bet links to betaenv.bet. There we can define a global variable
>and use it in all code below main.bet. But that seems not the right
>way.

>We think of using the objpool.get method, but then we will have to
>place it everywhere where we need a global variable. And we don`t know
>how fast this .get is, but we have time-sensitive code there.

>How do you do it ?

As you mention yourselves, using objectPool is one way.  This method
is only feasible, if either the global variables are used rarely, or
they are used intensively in localized areas of the program, such that
these areas of the program executes objectPool.get once, bringing the
global variables into some local variables.

However, in many program, this approach is indeed a good solution.


Another way is to construct an environment along the lines of the
different standard environments: xtenv, awenv, motifenv, guienv,
systemenv, etc.

These designs can be sketced like:

One fragment (myenv.bet) defines:

	myEnv:
	  (# ... global variables ...
	     ... global patterns ...
	     <<SLOT myEnvLib: attributes>>
	     private: @<<SLOT myEnvPrivate: descriptor>>
          do ... initialization of global variables ...
	     INNER myEnv
	     ... possible cleanup actions ...
	  #);


Then you can make fragments like:

	ORIGIN 'myenv'
	--- myEnvLib: attributes ---
	... define additional patterns ...

You can now define the private global variables in a fragment
(myenvprivate.bet) like:

	ORIGIN 'myEnv'
	--- myEnvPrivate: descriptor ---
	(# ... define private global variables ... #)

and have one or more implementation fragments like:

	ORIGIN 'myenv'
	INCLUDE 'myenvprivate'
	(* fragment forms implementing SLOTS in myenv.bet *)

etc.


Application programs now needs to utilize this environment, but this it easily done by:

	ORIGIN '...betaenv';
	INCLUDE 'myenv';
	--- program: descriptor ---
	myenv
	(# ... use the facilities defined in myenv, incl. global variables *)
	do ...
	#)

Regards,

   Jorgen Lindskov Knudsen, Computer Science Department, Aarhus University
   Ny Munkegade 116, DK-8000 Aarhus C, DENMARK
   E-mail: jlknudsen@daimi.aau.dk, Phone: +45 89 42 32 33, Fax: +45 89 42 32 55

   ************ BETA information Sources ************************
   * WWW:	http://www.mjolner.dk				*
   *	 	http://www.daimi.aau.dk/~beta/info		*
   * News:	comp.lang.beta					*
   * FAQ:	http://www.daimi.aau.dk/~beta/FAQ		*
   * E-mail:	info@mjolner.dk					*
   * Address:	Mjolner Informatics, Science Park Aarhus,	*
   *	 	Gustav Wieds Vej 10, DK-8000, Aarhus C, DENMARK *
   * Tel.:	+45 86 20 20 00					*
   * Fax.:	+45 86 20 12 22					*
   **************************************************************