Sorry Bill,
but I'm going to jump in here and start a flame war. I think you're
muddling up (MV) set theory with basic programming style and the
properties of the U2 compilers. From what I read it seemed that your
assertion was that you should only use equates when it is equated to a
variable? Which can only change synchronously with another variable? But
otherwise never? Or something?
I think most people would agree that by definition 'immutable' things
should not be variable. Mathematical constants like Pi or 'e' should
never change, red should always be red and a spade a spade. In
programming we try to emulate what happens in the real world (at least
that's what I read in this list fairly regularly).
In the top few other non-mv programming languages I can think of, they
give you key words to make immutability explicitly clear. Eg constant,
final, define, etc in UV you get to use EQU & LIT. These immutable
things like pi, or lists of colours, months etc I would argue should
never be variables (regional variants aside for this argument).
I think the use of equates in these types of situations is a good thing
and should not be discouraged. The ironically immutable, dynamic array,
list of credit card providers should be maintained as an equate and not
squelched back into a slush bucket variable.
[Being fair though, in this credit card case, it's not really an
immutable list; I probably would have tried to encourage the business to
own the credit card provider list and then have a subroutine which read
the values from an Accounts Department maintained lookup table. But...
for the sake of argument lets assume Visa and Diners Club are rocks on
which to build a future.]
So why do I think it's retrograde to encourage the developer to use a
variable instead of an equate? If one uses the assigned variable version
of VALID.CC.TYPES and somewhere in the guts of the program some
programmer overwrites the VALID.CC.NAMES variable then all of a sudden
you have to find out why 'V' has started returning ' Victorian Regional
Cost Centres' instead of 'Visa Card'.
If it had been an equate: the programmer could NOT overwrite or amend
the list by design or accident (or at least couldn't compile it) and it
could only have been changed at the EQU statement itself. Also, in this
case if the programmer decides to use the equated name but types it
incorrectly, there will normally be a compiler error. "Warning: Variable
'VAUD.CC.TYPES' never assigned a value."
The issue raised regarding an extract from an immutable dynamic array is
easily solved by putting brackets around the list or using the verbose
form of the extract statement. Eg. CRT 'Account name:
':extract(VALID.CC.NAMES,1,CC.PTR)
But there are also better patterns for handling equated lists than using
a dynamic array.
I also don't find anything limiting the usefulness of equates as an aid
to memory and a tool for simplifying code. They help catch some typo
errors, hide complexity, reduce the number of literal control strings
buried in the code and create a single place to amend code which may be
used several times in a program and can work like mini macros.
function GetCircumference(radius)
equ E.PI to 3.14159
equ E.CIRCUMFERENCE to E.PI * pwr(radius,2)
return(E.CIRCUMFERENCE)
end
More equates, fewer variables I say. Let the flames begin
Stuart
>-----Original Message-----
>I hate to mention the obvious, but one should not equate anything
unless they intend
>both sides of the equate to change when either variable changes. For
instance,
>
>DIM MYREC(30)
>EQUATE MYREC.DATE TO MYREC(1)
>EQUATE MYREC.NAME TO MYREC(2)
>--etc--
>
>Thus, whenever MYREC changes, due to a new record read, so does
MYREC.DATE,
>etc.
>Alternatively, you simply have to alter MYREC.DATE to make sure the
MYREC record
>has
>been changed too.
[snip]
>In all the years I've been doing this I've never run into these kinds
of problems
>because I follow the basic guideline noted. So, use an equate if both
sides can
>change. If that's not what you want make a simple assignment. There
is no reason,
>with today's machines, to create more complexity of syntax in order to
accomplish
>this simple task.
**********************************************************************
This email message and any files transmitted with it are confidential and
intended solely for the use of addressed recipient(s). If you have received
this communication in error, please reply to this e-mail to notify the sender
of its incorrect delivery and then delete it and your reply. It is your
responsibility to check this email and any attachments for viruses and defects
before opening or sending them on. Spotless collects information about you to
provide and market our services. For information about use, disclosure and
access, see our privacy policy at http://www.spotless.com.au
Please consider our environment before printing this email.
**********************************************************************
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
