[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Fri, 23 Jan 2004 00:35:31 +0000 
Subject:Re: Procedure Variables ??Help! 
From:Jeff Best 
Volume-ID: 

In message <bKWdneq3YPnM3Y3dRVn-vg@is.co.za>, not@top-post.?.invalid
writes
>"jattdemush"  wrote:
>> define useprice()
>> I WANT TO USE THE VALUE 'PRICE' HERE!!!!!
>> ...
>> enddefine;
>>
>In your code, the variable 'price' is not local/private to procedure
>'number', [nor any procedure] so it may be read or written by the
>'useprice' procedure, or any where else.
>------
>Do graduated examples:
>1. write to and read from global variables.
>2. write to and read from global variables in sisde and outside of procedures.
>3. make some variables local to some procedures: they can only be
>    'used' by their 'owners'.
>
>== Chris Glur.
>
>
>
>

Better still, insulate a procedure from the rest of its world. Give it a
simple interface that defines the external information it needs to be
supplied. Require all clients of the procedure to call it via the
interface. The procedure can then concentrate on doing what it is
intended to do, and so long as clients calling the procedure don't break
its "contract" with the outside world, it should be unaffected by any
changes outside its own scope.

Thus:

define useprice( price );
  ;;; Now "price" has local scope.
enddefine;

If we want to signal that useprice will accept a price and return a new
one, then:

define useprice( price ) -> newprice;
  useprice * 2 -> newprice;
enddefine;

Of course, this works even better if "price" can be rigorously typed.
The procedure can now happily sit in a quiet corner of the program,
doing its job, possibly for many years, without a care as to anything
that is going on in the rest of the program.

When this approach is taken, it is often the case that a "global"
variable (or instance variable/member), turns out to be nothing more
than a local variable of an outermost calling procedure or method.
Furthermore, anyone else reading the code can see our unambiguous
intentions regarding "price".

However, there are times when a "global" variable is recording some
aspect of the state of an instance, and therefore must be global in
scope to all of the methods of the instance. Even when
non-object-oriented code is being written, it is still a useful exercise
to consider how the state and methods might be partitioned into classes,
and organise purely procedural code in the same way. It is good to
provide comments adjacent to the procedure definition statement
indicating that a variable with global scope is to be regarded as an
implicit input and/or output to our procedure. It is also useful to
record in comments adjacent to the declaration of the global variable
that it will be used as an implicit input to our procedure. Further
comments can be placed in the adjacent upstream and downstream
assignments to the global variable, indicating that our procedure is a
location where the upstream value change will be consumed and the
downstream consumer will be affected by any change we make.

If we can convert our implicit relationship to an entity outside the
scope of our procedure into an explicitly declared relationship, then we
can probably reduce the commenting we need.

Managing the explosion of implicit relationships between blocks of code
is one of the hardest problems of programming. Maintainable programs
minimise implicit relationships.

Regards,
-- 
Jeff