Re: Done any string functions lately?

Let's use Prothon-dev for this discussion where our words of wisdom (or lack
thereof) can be enshrined forever.

Joe Knapka wrote ...

> OK, that's where I'm confused. It's not obvious that, for example, the
> result of "string".lower() is ever going to be del_unlocked. It seems
> that when, for example, Prothon code does "ABcdEF".lower(), the result
> of the lower() call should be added to the caller's environment (which
> I presume would be a "containment heirarchy rooted in
> global_objects"). There's probably an obvious way to do that, which I
> haven't noticed yet. Unless the interpreter code that invokes lower()
> is going to do that for me?

I have to admit that while I've thought through the rules, I haven't 100%
thought through the "standard practices".  I guess maybe putting this off is
going to cause a lot of pain when I have to go back through all this code :)

I went through a similar thing with the locking rules.  At first I coded
with the rules in place but I didn't follow them.  I didn't have the other
threads activated and the garbage collector wasn't running yet so I was
getting away with it.

In that case I really lucked out.  I put an automatic read_lock call on the
parameters of every function call and that covered 90% of the cases in one
fell swoop.  If you notice most of the methods in the modules have no read
or write lock calls at all.  Only methods that modify the object in place
need to make a lock call.

I suspect I'll be able to do a similar thing with the delete locking.  You
hinted at that in your question "Unless the interpreter code that invokes
lower() is going to do that for me?".

By the way, everything running at the Prothon code level WILL be in the
containment heirarchy because all scope objects that hold variables will be
in that hierarchy. The only objects that will need del_unlock attention by C
code are objects created for temporary purposes that never make it to the
Prothon code level.  Then they can be treated like malloc/free using
del_unlock.

For now, just use del_unlock() anywhere you know an obj is no longer needed
and you wish you could just delete it.  If you are passing it off to someone
else, then it's not your responsibility so don't worry about it.

That is another way to think about it:  Whatever code knows that the object
is no longer being used or has gone into the containment hierarchy is the
code that should call del_unlock().  If your code isn't sure about either of
these then leave it locked.   (I guess I could have just said that instead
of typing in this giant tome :)