I have a couple of questions about symbolics and the cost of transferring data via function arguments. I hope somebody will take the time to look at them even if they might be fairly trivial.

Let's say I have a PERSON table with fields FIRST_NAME, LAST_NAME, SEX, OCCUPATION, BIRTH_DATE, DEATH_DATE, ADDRESS, etc. Let's say I often need a condensed version of the PERSON rows, e.g for popups and lists. So I make a symbolic containing a few of the vital fields stringed together, with some punctuation (e.g, "Farmer Jon Fosse (1901-1977)"):

<code>

  Ret={OCCUPATION} : " " : {FIRST_NAME} : " " : {LAST_NAME}
  Dates={BIRTH_DATE} : "-" {DEATH_DATE}
  if Dates  "-" then Ret := " (" : Dates : ")"
  Ret=trim(Ret)
  @Ans=Ret

</code>

Actually I prefer to put the code in a function:

<code>

  function Make_Condensed_Person( Dummy )
    Ret={OCCUPATION} : " " : {FIRST_NAME} : " " : {LAST_NAME}
    ... etc ...
  return Ret

</code>

and just call the function from the formula:

<code>

  define function Make_Condensed_Person
  @Ans=Make_Condensed_Person( "" )

</code>

So far so good. But what if I need to make condensed versions of person data not in @Record? I could of course write a separate function with arguments instead, e.g:

<code>

  function Make_Condensed_Person_2( FirstName, LastName, Occupation, BirthDate, DeathDate )
    Ret=Occupation : " " : FirstName : " " : LastName
    ... etc ...
  return Ret

</code>

But duplicate code is harder to maintain. I'd prefer to have just one function.

An alternative would be to have just that second function and use that in the formula:

<code>

  define function Make_Condensed_Person_2
  @Ans=Make_Condensed_Person_2( {OCCUPATION}, {FIRST_NAME}, {LAST_NAME}, {BIRTH_DATE}, {DEATH_DATE} )

</code>

But how much is the cost of transferring data via arguments? This example is fairly simple, but I have some fairly complex symbolics to design. Some of them use other symbolics, and they again might use still other symbolics.

Does the cost drop much if I use only one array argument, e.g:

<code>

  function Make_Condensed_Person_2b( Row )
    $insert Person_Equates
    Ret=Row : " " : Row : " " : Row
... etc ...
  return Ret

</code>

(formula)

<code>

  define function Make_Condensed_Person_2b( Row )
  @Ans=Make_Condensed_Person_2b( @Record )

</code>

But I think that sometimes I'd prefer not to use an array, or not an array structured like the row.

What about a third alternative, with one function containing the code from both functions above? This will mean duplicated code for sure, but at least all the code is in one function and therefore easier to maintain:

<code>

  function Make_Condensed_Person_3( Rec, FirstName, LastName, Occupation, BirthDate, DeathDate )
    if Rec then
      ... calculate from @Record and neglect (the rest of) the arguments  ...
    end else
      ... no @Record. calculate from the arguments ...
    end
  return Ret

</code>

- Oystein -

R/BASIC and Basic+ parameters are passed by reference, always. (I some, some will argue that x:'' is a way to pass by value, but you're actually creating a new variable, passed by reference). The overhead of passing parameters is statisticly non-existant.

As a general rule, you should not pass @VARS in functions or subroutines, especially @RECORD or @ID or any other modifiable one. By design, they are active in the routine, so just use them.

If I were designing this style of program, I'd create a function will the full parameter set. I'd then check for the contents of the variables or see of they are assigned. If not, assume @RECORD is used. There would have to be checks to make sure that the name isn't Prince or Charo or someone without a last name sort of thing.

Another idea would be to pass in the record, key and file name and use the CalculateX function.

While I'm on topic, you should also avoid using {field} notation, if possible. Try and use @RECORD notation. You also shouldn't use {field} as parameter functions. There is some code that allows for revserse allocation of {field} values and you don't want some stray information to corrupt @RECORD.

[email protected]

Sprezzatura, Inc.

Aaron,

Thanks for your reply.

…overhead of passing parameters is statisticly non-existant.

I'm relieved.

As a general rule, you should not pass @VARS in functions or subroutines, especially @RECORD or @ID or any other modifiable one. By design, they are active in the routine, so just use them.

I see your point. But I am very good at not modifying parameters. If somebody asks me if I'm a good programmer I tell them I don't know, but at least I don't modify parameters.

There would have to be checks to make sure that the name isn't Prince or Charo or someone without a last name sort of thing.

Sure. With the kind of data my apps handle (i.e, not about famous people, but data that often isn't very complete) I have lots of tests like that.

Another idea would be to pass in the record, key and file name and use the CalculateX function.

CalculateX? Calcula T ReX? Isn't that extinct? Or did it survive its documentation? Time to dig out that old Advanced Revelation System Subroutines manual?

While I'm on topic, you should also avoid using {field} notation, if possible.

Thanks for the reminder! I often forget.

I actually have this utility to generate inserts with constants for all field numbers in all tables, so I can do e.g @Record instead of the slower {OCCUPATION} or dodgy @Record.

You also shouldn't use {field} as parameter functions. There is some code that allows for revserse allocation of {field} values and you don't want some stray information to corrupt @RECORD.

Could you please elaborate a little?

Thanks again for all your good advice!

- Oystein -

WOW .. i almost 100% agree ..

Use @record whenever you can .. why dup work. In the calling params use a boolean REC .. this way you don't have to worry about which pieces of data can be null etc.

[email protected] onmouseover=window.status=you have seen the rest .. now try the best!;return(true)"

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

CalculateX? Calcula T ReX? Isn't that extinct? Or did it survive its documentation? Time to dig out that old Advanced Revelation System Subroutines manual?

You could always do what I do periodically, just to remind myself what's about. Beat yourself with the keyboard repeatedly. No, actually, I'll run through the SYSOBJ list just to remember what's there and not documented. I beat myself with the keyboard because I enjoy it.

Could you please elaborate a little?

Never documented syntax, and not implemented in the standard compiler, but possibly implemented in older system compilers (and not in OI at all)

Assume the MYFIELD dictionary item points to position 1

{MYFIELD}=Kurt is Gd'

would set the @RECORD to 'Kurt is Gd'

With that, I've always been wary of passing in {FIELDS} since it's possible it could modify @RECORD.

Probably nothing to worry about. This is what happens when you spend to much time pouring through the meta code.

[email protected]

Sprezzatura, Inc.

Don't think I said not to use @RECORD, just not pass it. Either way, when it's available and what I want, I'll always use that. As a general rule, I don't read into @RECORD if I just want it in a variable, only when @RECORD is what's needed. I'd rather not trash it, if possible.

Not sure what you mean by boolean rec.

With you, Almost 100% is good enough for horseshoes or hand grenades.

[email protected]

Sprezzatura, Inc.

Aaron,

Not sure what you mean by boolean rec.

David referred to my suggestion of having a special parameter telling the procedure in no uncertain terms if it should use @Record or if it should use the other parameters. Your suggestion was to let the procedure use @Record if the other parameters were null. I tend to agree with David.

- Oystein -

Aaron,

What I meant was that in this case I'd agree with David.

- Oystein -

Aaron,

Thanks! I love you!

(Actually I didn't write that. I just hit myself with the keyboard, and that's what came out.)

- Oystein -

The old 10,000 monkeys syndrome, huh?

My nephew, all of 18 months old, once reached up to play with my keyboard and managed to press Ctrl-Alt-Delete. I see a career in software looming in his future.

[email protected]

Sprezzatura, Inc.

Aaron,

What I meant by boolean was to have a parameter called REC which is either true or false. If true then use @Record if false use data as passed. By checking REC you don't have to check multiple data params to see if the params are to be used or not.

In addition .. you can create a generic procedure in which the passed params are not specific to a table, window etc. Either use @Record or the params.

[email protected] onmouseover=window.status=you have seen the rest .. now try the best!;return(true)"

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

This might not be the answer you are looking for….

I have found that what you are concerned about is very minimal to system performance. I have software for Trucking and on the average they invoice from 200 to 800 freight bills a day. in short that is a great bulk of info and I have found that sometimes system performance

normally can be put second to the programmers preference (ease or choice of method of programming).

Debugging is much more easier when programming is done to your preference rather than to the system performance.

View this thread on the forum...