Re: Equates, object size and speed

On Jan 30, 12:36 pm, "Chandru Murthi" <cmurth_xyz@xxxxxxxxxxxxxxxxxxx>
wrote:
Excellent. You obviously have given this a lot of thought.

Unfortunately as my experience with Update/Forge has shown (and Ross would
probably agree,) it's a lonely row to hoe (is that the expression?)


<listens to chorus from the choir>

Yes, we give people LOTs of options --> for the die hards, you can
still use references like

customer.rec<3> = "a rose by any other name"

Like you & Peter we make equates from the dictionary (which actually
include the file name, avoiding the debtors/doctors "confusion"[?])
which can be INCLUDEd), so you can write code like

crec<arCustomer_name> = "a rose by any other name"

or

aDimRecord(arCustomer_name) = "a rose by any other name"


My personal preference is to use a totally abstracted reference, like

call wl.setValue("arCustomer_name","a rose by any other name")

which will also go and apply "validations" based on the dictionary
(schema) .... and it also makes it dead easy to suck data in from a
web service or excel spread***! (further simplifications via
"snippets", but that is another story),

<snip>

While you mention the possible lack of flexibility when using a "schema," I
think of nothing like the weird and wonderful SQL or other schemas around.
I'm merely thinking that if one had a good RAD, the definition of the
database files could be automated so that you'd at least not screw yourself
if you followed the rules.


Essentially what our get/setValue routines do - the "schema" is a live
& active part of the application itself, and our upgrade/install
processes will make files, dictionaries etc just like you would expect
from SQL types (aside: we actually used to market an add-on to
Rational Rose that did the same sort of stuff from UML, before RR
included the capability as a standard feature for the SQL world)


Since you could always code RECORD<17,2>=JUNK if you were so inclined, Pick
can never be completely free of problems. Or referential un-integrity.

Actually, you CAN catch this, if you REALLY wanted to, either by
banning "native writes" from BASIC code (pre-scan by intercepting
COMPILE/BASIC with your own) and/or throwing a trigger on the file
that does all of the checking --> but then again, the attraction of
Pick/MV has always been the abundance of rope!! (and other traps)

As recently as a few years ago, when I looked at jbase's web RAD (ims) it
dealt with multivalues so poorly that it was a joke, and did not use any
kind of standardized Dict structure to boot. So it's left to the poor
programmers to enforce some kind of minimal standard. And using EQUs is only
a first step.


The first of MANY! I believe that one of the great strengths of Visage
is the power and elegance of a clearly defined and readily understood
naming convention, and the support tools to leverage this. Anyone like
to guess what might be happening here :

call
wl.getValue("oeInvoice_deltoCustomer_arCustomer_emailAddress",emailAddress)

A lot of typing did I hear you say?

Would you prefer :

open "","oeInvoice" to fv.oeInvoice else filename = "oeInvoice" ; goto
fileOpenError
open "","arCustomer" to fv.arCustomer else filename = "arCustomer" ;
goto fileOpenError
....
....
emailAddress = ""
read rec.oeInvoice from fv.oeInvoice, key.oeInvoice then
read rec.arCustomer from fv.arCustomer,rec.oeInvoice<2,1> then
emailAddress = field(rec.arCustomer<39,1,2>,"*",1) ;* nothing like a
nasty structure!!
end
end


A long way from object size & speed I know, but if you look at a
metric like development & maintenance costs over the life of your code
(bottom line stuff), I know which way approach/techniques will come
out in front :-)
.