xkapastel has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #picolisp
razzy has quit [Ping timeout: 245 seconds]
razzy has joined #picolisp
razzy has joined #picolisp
razzy has quit [Changing host]
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 248 seconds]
razzy has quit [Ping timeout: 268 seconds]
ubLIX has joined #picolisp
orivej has joined #picolisp
beneroth has quit [Read error: Connection reset by peer]
stultulo has joined #picolisp
ubLIX has quit [Quit: ubLIX]
f8l has quit [Ping timeout: 245 seconds]
stultulo is now known as f8l
orivej has quit [Ping timeout: 245 seconds]
beneroth has joined #picolisp
<beneroth>
hi all
<beneroth>
Regenaxer, (low priority) what is the purpose of the function 'lose in @lib/db.l ?
<beneroth>
(de lose "Prg"
<beneroth>
(let "Flg" (: T)
<beneroth>
(=: T T)
<beneroth>
(=: T "Flg") ) )
<beneroth>
(run "Prg")
<beneroth>
I cannot find any call to it
f8l has quit [Remote host closed the connection]
f8l has joined #picolisp
<Regenaxer>
He beneroth
<Regenaxer>
Good question
<Regenaxer>
I don't remember exactly atm, but it seems to be a utility to operate on already "lost" objects
<beneroth>
aye, preserving the value of the T property when doing something
<Regenaxer>
"lost" objects do not handle indexes for example
<Regenaxer>
T
<beneroth>
though I don't know when there would ever be a value in the T property
<Regenaxer>
T is a marker
<beneroth>
a flg
<beneroth>
no?
<Regenaxer>
Set by lose>
<beneroth>
aye
<beneroth>
not important, just stumpled on it
<Regenaxer>
I also cannot find a use case
<Regenaxer>
IIRC it was some maintenance
<Regenaxer>
Same with 'keep'
<Regenaxer>
I think 'lose' is there for symmetry
<Regenaxer>
I find 2 use cases for 'keep', so 'keep' is the main reason perhaps
<beneroth>
ah ok
<beneroth>
yeah would keep it.
<Regenaxer>
I find (keep (put!> This 'bt NIL))
<Regenaxer>
in a replication code
<beneroth>
what is the use case for doing (upd> This (val This) Val) at the end of (set> '+Entity) ?
<Regenaxer>
This is used very often
<Regenaxer>
Many DB classe define 'upd>'
<beneroth>
I mean nice that upd> gets called as the value changes. but I think a (custom) upd> cannot differ between change of a property and change of symbol value (class list)
<beneroth>
yeah I'm using upd> too. very handy.
<Regenaxer>
custom upd> can detect any change I think
<beneroth>
but at the moment I have some ugly logic within my upd> method to determine what exactly happened (object newly created, property changed, boolean property changed, object deleted, class changed, ...)
<beneroth>
not sure if I'm doing that right
<Regenaxer>
This is all passed
<beneroth>
how so?
<Regenaxer>
Let me find an example
<beneroth>
I think I only get Var Old
<beneroth>
you mean there are additional parameters I could capture?
<beneroth>
cond on the arguments to determine what happened
<Regenaxer>
yes
<Regenaxer>
or casq often
<beneroth>
I wonder if it might be more elegant to extend the argument list of upd> to pass that info, as the source issueing the upd> call usually has this knowledge
<beneroth>
instead of encoding it in this 2 parameters
<beneroth>
Do you have thoughts on that?
<beneroth>
maybe it could be solved by additional parameters, so it does not break your existing code
<Regenaxer>
What would that improve?
<beneroth>
less involved (cond)
<Regenaxer>
In 90 percent of the cases I check (casq X
<Regenaxer>
new and lose are seldom
<beneroth>
hm... right
<Regenaxer>
eg
<Regenaxer>
(dm upd> (X Old)
<Regenaxer>
(casq X
<Regenaxer>
(mes (put> This 'm T))
<Regenaxer>
(bud (put> This 'm NIL))
<Regenaxer>
((dat pu)
<Regenaxer>
(and Old (put> @ 'e NIL))
<Regenaxer>
(and (get This X) (put> @ 'e This)) ) )
<Regenaxer>
(super X Old) )
<beneroth>
same here, in application code. but I have (optionally to be activated) mechanism in my extra db layer to do automatic logging of data changes, which is implemented by a parent class implementing upd>
<beneroth>
ok
<beneroth>
well good to know I'm actually using upd> the intended way then :)
<Regenaxer>
Yeah, as usually! :)
<beneroth>
thanks
<beneroth>
hopefully
<Regenaxer>
you found most out by studying the sources
<beneroth>
T
<beneroth>
I greatly enjoy being able to read the source the complete stack downwards
<beneroth>
no turtles, just nice parens ;-)
<Regenaxer>
:)
<beneroth>
you got a moment to help me to improve my upd> cond ?
<beneroth>
I've got currently:
<beneroth>
(nor Var Old) -> lose
<beneroth>
((=T Var) -> keep> (undoing lose>)
<beneroth>
(oh..not in that order)
<Regenaxer>
Why (nor Var Old) -> lose ?
<Regenaxer>
Old value may exist
<beneroth>
(lose> '+Entity) is doing (upd> This) at the end
<Regenaxer>
ah, ok, no Old
<Regenaxer>
ok
<beneroth>
T
<Regenaxer>
but (cond
<Regenaxer>
T is new
<Regenaxer>
17:27 <beneroth> cond on the arguments to determine what happened
<Regenaxer>
sym is propery
<Regenaxer>
ok
<Regenaxer>
17:27 <beneroth> ok, so you do it the same way as I do
<Regenaxer>
pair is class change
<Regenaxer>
yes
<Regenaxer>
or casq often
<Regenaxer>
17:28 <beneroth> I wonder if it might be more elegant to extend the argument list of upd> to pass that info, as the source issueing the upd> call usually has this knowledge
<Regenaxer>
17:28 <beneroth> instead of encoding it in this 2 parameters
<Regenaxer>
17:29 <beneroth> Do you have thoughts on that?
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<Regenaxer>
oops
<beneroth>
wb :D
<Regenaxer>
Wrong paste
<beneroth>
np
<Regenaxer>
I wanted to say (cond ((not X) ... is enough
<beneroth>
at the moment (list? Var) I use to detect (new)
<beneroth>
probably wrong
<Regenaxer>
yeah, cause NIL is also list
<Regenaxer>
(pair Var) is better
<Regenaxer>
I call it X cause it may not be a 'var'
<beneroth>
T, but the parameter is named Var
<beneroth>
one could argue that is wrong
<beneroth>
surely named so for historic reasons
<beneroth>
at beginning it was only for property changes, and then the usage got broader
<beneroth>
aye?
<beneroth>
(while property changes is still the primary application ofc)
<Regenaxer>
In the caller it is Var in the 'put>' etc
<beneroth>
oh
<beneroth>
you are right
<beneroth>
the default is (dm upd> (X Old))
<beneroth>
I should rename Var in my upd> method
<beneroth>
right!
<beneroth>
thanks! my fault :D
<Regenaxer>
just to be mnemonic
<beneroth>
T
<beneroth>
well, important for maintenability
<Regenaxer>
true
<Regenaxer>
and not to confuse a reader
<beneroth>
ok, so to wrap up: (in that order) (cond ((not X) 'lose) ((pair X) 'new) ((=T X) 'keep) (T 'property-change)) ?
<Regenaxer>
yeah
<Regenaxer>
in the most general case only
<beneroth>
I would prefer re-ordering, as the most common call is property-change, but I think I cannot for proper determination?
<Regenaxer>
typically only one or two syms are of interest
<beneroth>
ah yes, of course
<Regenaxer>
With 'casq' you can also cover NIL
<Regenaxer>
but not T
<beneroth>
this is upd> implementation for doing full logging of all data changes, including new and deletion. not application logic upd>
<Regenaxer>
ok, yes
<Regenaxer>
I have such in a +Hist prefix
<beneroth>
oh, would you send me the +Hist definition? :D
<Regenaxer>
I have similar ones in most apps
<beneroth>
yeah it's often useful in ERP applications, when you need a trail of data changes for audit or data quality purposes. or undo/redo.