Is a gramps id unique within one database? I thought it was.
And handles are unique within a database and have a good chance of being unique across all databases?
The Gramps ID is not defined as unique in the schema, and does not have a unique constraint in the database. However the GUI does provide a GEDCOM format as default and should warn of duplicates.
Handles are unique within a table because they are used as the primary key. In practice they are probably also unique in the database. If one database is derived from another, then it is possible that handles are not unique across databases.
I was taught that the main reason for high level programming languages was to make code readable.
Your aim appears to be to reduce the method names in length. Why not go the whole hog and replace all method names by a number. The method name could then be reduced to five or six characters. The code would be shortened and made completely unreadable.
The current method names, mostly, say what they do. They are therefore eminently readable. There may be some which could be improved.
I think you missed the point of the renaming: they are currently inconsistent with each other and they might as well be random numbers. You canāt tell what a method name is by guessing; you always need to look it up. Any shortening is going to be consistent across the names.
Is this the Gramps-Devel thread you were recalling?
Just a thought butā¦
Isnāt this (analyzing existing method naming patterns, comparing them to common implementations, assessing previous discussions, and suggesting a coherent harmonization) an ideal application of LLM tech?
Actually, it is the opposite: if we come up with good names, AI agents will be able to use them efficiently and effectively.
Would it be good at doing a final sanity check before implementing?
It might catch something, but so will other humans reviewing the PR. But weāll trust our human colleagues over any AI.
This is exactly the problem that I am trying to solve (or at least reduce). As a semi-regular gramps developer I still find that I am having to lookup a method name. For something as common as db access, I believe we can do better than the current API names.
That is a secondary consideration. Consistency and clarity are more important. Given a choise of two equally clear and consistent names, then yes Iāll prefer the shorter one - less typing initially and more importantly less to read in future. For every piece of code written, it will be read many times during itās lifetime.
Absolutely, some names I left as-is. Please contribute your ideas for improving those which you think could be improved. Collectively weāll arrive at a better set of proposed names than I will on my own.
No, @SteveY I was thinking about the original Switch from pickled blobs to JSON data #1786 and specifically the comment thread that I started [Gramps-devel] Switch from pickled blobs to JSON data #1786 - Abstraction . My point was that the change was introducing (at least) three different representations for Gramps objects, Object, dict, and string. But the naming conventions for conversions of these things was all over the place.
It then turned out that there were more representations, plain dict and wrapped dicts.
I think that Doug suggested that he might make the naming and structures a bit more consistent - I not sure whether that actually happened.
I view of another thread here Difference in DataDict vs Object Behaviour , it would seem that there are more complexities about the behaviours of the different representations, which IMHO makes it even more important to make the code absolutely clear even at the expense of some increase in length of method names (after all, code is read far more than it is written).
Strongly disagree. As I have said elsewhere, code is read more than it is written, so a small amount of extra effort when writing code is worth it to make the code clearer.
To misquote Einstein, āthe name of a method should be long enough to clearly understand its intention, but no longerā.
I accept that my initial statement was terse. But in the context of the bullet point where I said this, I stand by it. Dropping _from_handle and ultimately moving to "combine handle and gramps_id forms of methods " is in my view a good thing. We should not have to describe every parameter type in method names of a well designed API. We can rely on tooling to tell us when we fallible developers get it wrong.
Iāve said much the same above
ā¦ Consistency and clarity are more important. Given a choice of two equally clear and consistent names, then yes Iāll prefer the shorter one - less typing initially and more importantly less to read in future. For every piece of code written, it will be read many times during itās lifetime.
Iām not sure how the proposal helps to avoid guessing what the method name might be.
How about standardising get_thinga_from_thingb. For examples,
-
Column 1 Column 2 Column 3 Column 4 thinga thingb current name possible new name person_object handle get_person_from_handle get_person_object_from_handle person_object gramps_id get_person_from_gramps_id get_person_object_from_gramps_id person_datadict handle get_raw_person_data get_person_object_from_handle person_object person-datadict get_person_object_from_person_datadict
We also have the raw string as stored in the database and there is apparently some distinction between wrapped and unwrapped data dictionaries. Iām not sure where these appear in the interface. [raw strings seem to appear in _iter_raw_data where strings are converted to ādataā - presumably datdict].
I appreciate that this makes the names very long, so I am not sure how serious this suggestion is. As in my comment on conversion to JSON, I want to point out how inconsistent the current code is.