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 spreadsheet! (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 :-)
.

Relevant Pages

  • Re: Considerations for a better Import/Export Format
    ... References is made to XML purely for illustration. ... The character set should be global which nowadays means UTF-8. ... I believe it's easier to use a bottom-up representation. ... The issue, as always, is not so much an issue with the current standard, ...
    (soc.genealogy.computing)
  • Re: Cost of ownership: MV vs. SQL Server
    ... >>If you are using SQL against MV, for example, ODBC would be your best ... > the alternative "Zero Touch Deployment" available with .NET. ... non-MS client environments? ... > as "standard" as any connectivity tool is going to get in our market. ...
    (comp.databases.pick)
  • Re: Writing huge Sets() to disk
    ... >> state and taking say 600MB, pushes it's internal dictionaries ... that this code takes a lot of extra memory. ... >> I believe it's the references problem, ... the swapspace reserved grows during that posted loop. ...
    (comp.lang.python)
  • Re: Why no standard words for traversing a wordlist?
    ... standard Forth provides a great many features for extensibility of the ... wordlists in the current search order. ... most dictionaries would contain a back- ... Returns the xt of THING (the 'flags' portion (immediate etc) is ...
    (comp.lang.forth)
  • Re: So whats null then if its not nothing?
    ... Because way too many people started writing half-baked study books about ... SQL when it became booming business. ... >"A good standard survives because people know how to use it. ... But I've also seen you write that it's equal to the empty ...
    (comp.databases.theory)