> From: Mark Johnson
> Not for nothin' but there are some pretty ugly I-type dict
> items with all the SUBS, EQS, REUSE etc stuff.
Before I disagree with some points, let me concur that I-types'
MV-handling can be ugly.
Although Prime traded the ugly correlative syntax for the inherent
simplicity and familiarity of I-type's BASIC syntax, for MV handling,
Prime traded simplicity for power.
Pick-style correlatives are written to handle each value separately.
You write single-valued logic and the query language is responsible for
feeding each value through the correlative as needed. The downside is
that it is hard to explicitly manipulate dynamic arrays with their
embedded delimiters from a correlative like you would in Basic.
Prime-style I-types allow (i.e., require) you to manipulate entire
system-delimited dynamic arrays like you can in basic. That allows you
to do stuff that is very difficult or impossible with Pick-style. But
it forces using EQS, REUSE, etc, when you wish you didn't have to.
If I had my way we'd have an additional feature that would allow you to
write singlevalued logic, first declaring the associated mv strings to
loop through. Something like:
FOR {list of associated mv fields} LOOP { single valued logic }
Here is a simple example where a correlative is nicer. It builds the
full name putting a comma between last & first names, or uses just the
first or last name if only one is not blank (All errors are the
responsibility of the reader.)
- Singlevalued:
SURNAME:(IF LEN(SURNAME)& LEN(FIRSTNAME) THEN ', ' ELSE ''
):FIRSTNAME
- Multivalued (UV):
CATS(CATS(SURNAME,(IFS(ANDS(LENS(SURNAME),LENS(FIRSTNAME)),REUSE(',
'),'')),FIRSTNAME)
or if you prefer:
ANDS(LENS(SURNAME),LENS(FIRSTNAME)); IFS(@1,REUSE(', '),''); CATS(
SURNAME,@); CATS(@,FIRSTNAME)
- My wish:
FOR {SURNAME,FIRSTNAME,REUSE(', ')} LOOP {SURNAME:(IF
LEN(SURNAME)& LEN( FIRSTNAME) THEN ', ' ELSE '' ):FIRSTNAME}}
Now, MV-handling aside :
> I don't have
> an example, but I worked on a client's system that was
> converted from UV to UD and all the 10 line dicts were
> converted to the UD 6/7 ones (saving the original 10 line
> dict in field 10 of the UD one) and 002 became pretty
> excessive and unreadable. They did work though.
Don't judge I-types by the output of an automated converter !
If a real live programmer had started from scratch and written in the
most natural way, they'd be a thing of beauty.
Plus some of the system's basic reports would have been written in the
Uniquery - far superior to English/Access - further simplifying and
making more maintainable the system as a whole.
> IMHO, having many years of experience with UD/UV/D3/MCD/ULT and native
> dict items,
IMPHO, most people generally give up on the query language way _w_a_y_
WAY too soon and start writing less flexible, less maintainable reports
using Basic. Part of the reason is most of their experience is with
limited Pick- instead of Prime-style dictionaries & query language. Or
they learned from people & systems with that background.
> UV's is the most advanced
I-types, maybe, but the query language is the other glove. While both
UD/UV are superior to D3/MCD/ULT, UD's UniQuery is more sophisticated
than UV's RetrieVe because it better handles subvalue associations and
also 2 or more _independent_ associations within the same UniQuery
command.
UD's I-types (aka V-types) need the mv functions instead of subrs,
though. For UD, that FullName example above becomes something like:
SUBR('-CATS',SUBR('-CATS',SURNAME,SUBR('-IFS',SUBR('-ANDS',SUBR('-LENS',
SURNAME),SUBR('-LENS',FIRSTNAME)),REUSE(', '),'')),FIRSTNAME)
> as it can support both the 10 line that I
> (we) grew up on and the 6/7 line UD style.
Yes, UV's all-things-to-all-men philosophy.
For maintainability's sake, abandon the 10 line whenever you get the
opportunity and learn to write complicated reports using Itypes &
UniQuery/RetrieVe or SQL.
Pigheadedly yours,
Chuck Stevenson
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
