*any unintended consequences?

Writing and using plugins for Version 5 and above.
User avatar
Ron Melby
Superstar
Posts: 320
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

any unintended consequences?

Postby Ron Melby » 13 Jun 2019 12:19

2 situations, sometimes I want to know values, and sometimes I want to write them out. I have chosen a trivial example it is offset by ****.
rtvSEX = retrieve sex
matSEX = materilize sex (write it out)

so, given each circumstance, I can either inspect it, or write it out (when called 'directly')
any down the road problems you can think of with this?

Code: Select all

function rtvSEX(iptr)
  local  thisPTR    = iptr
  local sex = matSEX(thisPTR)
  return sex
end -- fn matSEX

function matSEX(iptr)
  local  thisPTR    = iptr

  tblSEX = tblSEX or {}
  cwsex = cwsex or 6

  local sex = string.sub(fhGetItemText(thisPTR,'~.SEX'), 1, 1)
  if sex == '' then
    sex = 'U'
  end

****
  local cs = debug.getinfo(2, 'n')
  if cs.name ~= 'rtvSEX' then
    table.insert(tblSEX, sex)
  end
****

  return sex
end -- fn matSEX
FH V.6.2.7 Win 7 64 bit

User avatar
tatewise
Megastar
Posts: 15907
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: any unintended consequences?

Postby tatewise » 13 Jun 2019 13:40

That should work Ok, but seems a rather complex method.
Why not have one function with a parameter that identifies whether to save the value?
e.g.

Code: Select all

function getSEX(iptr,save)
  local sex = string.sub(fhGetItemText(iptr,'~.SEX'), 1, 1)
  if sex == '' then sex = 'U' end
  if save then
    tblSEX = tblSEX or {}
    cwsex = cwsex or 6
    table.insert(tblSEX, sex)
  end
  return sex
end -- fn getSEX
then
local sex = getSEX(ptr,false) or local sex = getSEX(ptr,nil) or local sex = getSEX(ptr) will retrieve without saving
whereas
local sex = getSEX(ptr,true) or local sex = getSEX(ptr,"Save") or local sex = getSEX(ptr,1) will retrieve and save

BTW: I've noticed you often start functions with local thisPTR = iptr that is unnecessary as iptr is already a local variable.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Superstar
Posts: 320
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: any unintended consequences?

Postby Ron Melby » 14 Jun 2019 06:00

So if I dispense with thisPTR I would not need a
local iptr = iptr (as a speedup measure?)
FH V.6.2.7 Win 7 64 bit

User avatar
tatewise
Megastar
Posts: 15907
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: any unintended consequences?

Postby tatewise » 14 Jun 2019 09:25

Correct.
The iptr parameter is by definition a local variable already.
It is only in scope within the function, just like any explicit local variable.
Lua says:
"Parameters act as local variables that are initialized with the argument values"
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Superstar
Posts: 320
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: any unintended consequences?

Postby Ron Melby » 15 Jun 2019 12:48

ok, I have cleaned up my standard functions to dispense with thisPTR

no noticable difference yet.

there will be a new post in this continuing saga, in search of speed.
FH V.6.2.7 Win 7 64 bit


Return to “Plugin Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest