For some reason, I cannot see Grant's messages in the thread in gmail. I was able to read the message by visiting mail-archive.
Thanks Grant for your updated sample ... I am in the process of GUIfying the todo sample https://picolisp.com/wiki/?taskDB Regards, Kashyap On Mon, Sep 2, 2019 at 2:14 AM Alexander Burger <a...@software-lab.de> wrote: > Hi Grant, > > > > In general it is not recommended to keep DB objects in globals, as > they cannot > > > be garbage collected. > > > > > > ☺/ A!ex > > > In the `family.l` example it seems to store the "current person" object > in the > > `val` of *DB. Is this just for convenience for the sample? Or is this > > different since the global symbol isn't a reference to the object itself? > > This is ok. With "globals" I meant global internal symbols. '*DB' holds an > *external* symbol, i.e. '{1}', which is the root object of the database. > > So what "family.l" does with > > (set *DB (request '(+Man) ... > > is create a new '+Man' object and store it in '{1}' in the database. > > The global '*DB' is not changed here (and in fact never should be; it > should > always point to '{1}') and is known by the system - most notably by the > garbage > collector. > > > > I assume the correct pattern for an action form is to use some global to > hold > > a reference to some indexable ID for the DB object we are interested in? > > This is possible, but typically nothing is kept globally, and the user is > presented a search dialog ('choPerson' in "family.l"). > > Note that in fact the GUI *does* use a global '*ID' but this gets a new > value > with each form and thus does not inhibit the previous values to become > garbage. > > Also, search dialogs typically keep searched values in globals ('*PrsNm', > '*PrsJob', '*PrsDat1' etc.) to allow the user to search for similar things > in > the same context, but these values are strings, numbers, dates etc. and > not DB > objects. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
