20231130 Raydata rename all uid to scan_uid

[e-carlin]

uid means something in Sirepo (users id). So, can be confusing when reading raydata code for uid to mean something else (the uid of the scan). I think renaming to scan_uid globally will fix this.

[robnagler]

How about a moniker "rdid" or "rduid"?

[rorour]

I think scan_uid is clearer and conveys more useful info than rdid/rduid.

[e-carlin]

I have the same reaction to rdid and rduid that they are not very clear. And, as you can see by the name I suggested, it isn't my natural inclination to pick them. But, over time I've come to appreciate names like that because they "become language". To someone first looking at our code scan_uid is clearer. But, over time the name rdid/uid starts to mean something specific and is unlikely to get confused w/ anything else in the future. Also, they are shorter. Finally, (and I just realized this) not having underscores in the name is nice. It avoids all of the confusion converting camelCase to snake_case (which I just ran into). I'm not totally wed to rdid/uid but short, unique, and w/o underscores I am for.

[rorour]

Good points. I think rduid is good then.

[robnagler]

Nice points, everyone. I think it's a tricky problem especially in our domain with its boundless acronyms and lingo with each new app.

In the beginning, we thought what's a "uid"? There was much confusion (for me, at least). It obviously conflicts with the Sirepo concept and the general programming concept of user. It's not a user id. Leaving it standalone as in "scan uid", I found it very confusing with our lingo. By smashing it together with other (essentially random) letters, the "u" has diminished emphasis so it is not automatically bound to "user" in my mind.

In "natural" language, this "uid" would be called a false friend. I've started reading a German language newspaper the last week or so. False friends abound in German, since they are so close to English. I don't think we give enough credence to false friends in programming.

I was also thinking about variables with https://github.com/radiasoft/pykern/pull/395#issuecomment-1714871586. The variable names were long and confusing to me. The use of "tail" made me think of tail recursion. This particular statement bothered me quite a bit:

iterables = iter(iterables)

This was extremely common in my early days of programming. It would save stack space to reuse variables. That's a red herring nowadays. In Python this is very confusing, because an iterable may be an iterator, but an "iterator" always is an "iterable". The statement above is linguistically correct, because by definition iter always returns an iterable. However, it contains no information, and would imply that you might not need to execute iter. Rather, iter always returns an iterator so:

iterators = iter(iterables)

Why go to such great lengths about this? Because the long variables confuse instead of help. If you miss the iter statement, you think that iterables is what's passed in. It's highly imperative code. If a statement gets moved, behavior will be confusing.

Naming is very hard, and it's worth spending the time on the language.

[rorour]

If uid in Sirepo is not user id, what is it?

iterators = iter(iterables)

Why didn't you end up doing it this way?

[robnagler]

If uid in Sirepo is not user id, what is it?

The uid of this issue is a Bluesky uuid identifying the scan. It is not a Sirepo concept.

Why didn't you end up doing it this way?

I just copied the code from the original. I started to refactor but then thought better to leave as is.

[rorour]

In the beginning, we thought what's a "uid"? There was much confusion (for me, at least). It obviously conflicts with the Sirepo concept and the general programming concept of user. It's not a user id.

My mistake, I was confused by your wording here. I thought you were saying that "uid" in the Sirepo database is not a user id.