Re: Date manipulation

From: Judson McClendon (judmc_at_sunvaley0.com)
Date: 12/23/03 

Date: Tue, 23 Dec 2003 15:53:24 GMT

"Peter E.C. Dashwood" <dashwood@enternet.co.nz> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
> > "Ron" <NoSpam@NoMoSpam.ORG> wrote:
> > >
> > > Actually only two moves are necessary but whatever...
> > > move date1 (1:2) to date2 (5:2)
> > > move date2 (3:4) to date2 (1:4) ...
> >
> > I agree with you about the two moves, but I really don't think using
> > address modification on fixed field moves like this is a good idea,
> > from a maintenance standpoint.
>
> Why not? It is highly efficient (resolved at compile time) and self
> documenting.

Self documenting? Not! The form "date2 (3:4) to date2 (1:4)" tells
you nothing about what part of date2 you are moving. You must
examine both the definition of date2 and, if all references to it
are like this, also the procedure code that uses it. Why do we have
data names in the first place? Clarity! Consider, if date2 is defined
ONLY as 9(08), no redefines, and EVERY reference to parts of
date2 are by reference, how are you going to know what the format
is? You must examine the actual references to date2 and decipher
them, which may not be easy, because, since all the references to
parts of date2 are by address modification, you will need to find a
move between date2 and a date field whose structure is known. If
the same procedure (definition and reference) is followed on all
the date fields, then only if a move between date2 and a standard
date field is found will you know what the format is. :-)

> How does it complicate maintenance to know what offset and length of a field
> is being moved?

None. It is the NOT knowing the name (sense) of the data that is
being moved that is the problem. :-)

> > Address modification is great for use
> > in scan loops, and with STRING/UNSTRING, or otherwise where
> > you cannot use group levels effectively. And in a few other specific
> > and clear (and not likely to change) situations like extracting the first
> > character of a name. But for fixed field moves, always use:
>
> Disagree strongly. These are arbitrary rules based entirely on style (your
> opinion) and presented as "good practice".
>
> I have no problem with you doing things this way; I have a problem with you
> presenting YOUR way as being the best (or only) way...

I have no problem with you being ignorant of how human perception
works, vis-a-vis programming techniques; I have a problem with you
assuming YOUR lack of knowledge applies to all of us... ;-)

Pete, has it occurd to you that someone can know something for a fact,
that can be studied and easily demonstrated, yet you are unaware of it?
Trust me, this can happen. Just because you are unaware, or disagree,
with a provable fact, is no proof that it is incorrect. I have absolutely
no doubt of the CERTAINTY that using address modification in the
way you suggest is LESS CLEAR than using well named fields. Not
only is it logically obvious to me, but clearly understood and well
documented characterists of human perception, and years of actual
trials I have done, are clear enough proof for me. Simple proof by
reductio ad absurdum makes it obvious that this is true, because if you
continually applied this principle to all such references, the result
would be only address modification references into a huge, undefined
memory pool (i.e. machine language references). If data names are
better understood than pure memory references in general, they are
also better understood here, since precisely the same principles apply.
:-) 

-- 
Judson McClendon      judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Relevant Pages