[Core] Create ElementMap.h and tests

[AjinkyaDahale]

ElementMap.h for now contains a list of constants which will be used in the ElementMap class in a future phase of toponaming solution.

Intended to fix #8768.

[AjinkyaDahale]

As mentioned in a comment in the issue, I have not moved constants from TopoShapeOpCode since it did seem to belong to Part-specific items.

[AjinkyaDahale]

@realthunder are there any other constants that can be stored here? Also, question, where are the mod/gen/upper/lower strings in your own branch?

[JohnAD]

@AjinkyaDahale

My thinking of moving the TopoShapeOpCode items was that future programmers would find it convenient to have a single place to "interpret the meaning" of a particular mapped name. Since since these are simple constants from a standard default workbench, it would not add much complication to the Part workbench later.

Is the new TopoShapeOpCode.h file more about the naming algorithm or more about the Part workbench? It is both; so there is not a clear answer for where to put them.

If you are keeping them separate, you might consider placing the TopoShapeOpCode.h into the Part workbench now, and place a comment reference in the ElementMap.h file to the TopoShapeOpCode for future programmers to follow.

[AjinkyaDahale]

Is there a reason to store constants as char* instead of std::string or anything else?

[chennes]

See https://github.com/KDE/clazy/blob/master/docs/checks/README-non-pod-global-static.md

[adrianinsaval]

Why is this the only one that doesn't have a :? It looks odd. And for that matter, why do all the others have a : anyways?

[AjinkyaDahale]

I believe the answer to the first is there may be other meanings when the : is not used. As for why this particular postfix doesn't have the colon, I'm just taking it from the issue. I don't see it used in the development/toponaming branch, but RT may have just not merged it.

[AjinkyaDahale]

@JohnAD @realthunder could you pitch in?

[realthunder]

My intention is for ;: as the separator for a postfix that may be used for parsing later on. ;D is not exposed in my original code as a postfix. It is internally used as a default way to rename duplicated element that may be overridden by derived class.

[adrianinsaval]

TopoShapeOpCode.h has mostly Part WB specific stuff but I also see some mentions of sketcher and draft, presumably when implementing the algorithm on other WBs one would want to add the op codes for those there too so unless we're going to split those for each workbench I think it might make more sense to move it into App

Note that I'm very much an amateur so don't take me too seriously.

[AjinkyaDahale]

TopoShapeOpCode.h has mostly Part WB specific stuff but I also see some mentions of sketcher and draft,...

AFAIK Part is used in those WB's as well.

I do expect there may be other such WB specific names. Can't think of operations right now, but I'm sure there may be operations that are defined for, say path, but not used in part.

[freecadci]

for feature branch PR_8923. Pipeline 812852228 was triggered at e3ced6c. All CI branches and pipelines.

[freecadci]

for feature branch PR_8923. Pipeline 813228988 was triggered at 5fdde9d. All CI branches and pipelines.

[AjinkyaDahale]

See https://github.com/KDE/clazy/blob/master/docs/checks/README-non-pod-global-static.md

@chennes I've replaced the std::string global vars with char* now.

[chennes]

Awesome. I'm thinking we'll hold the merge for a short time here to see if either @realthunder or @JohnAD can comment on the : syntax question above. That feels like something we want to make sure we understand before going too much further. When you have a minute can you take a look at #8974? There wasn't a lot to do there, so it should be a fast review.

[freecadci]

for feature branch PR_8923. Pipeline 813587061 was triggered at 125eacd. All CI branches and pipelines.

[realthunder]

The first priority of the topo naming encoding scheme is to generate unique and stable names for geometry elements. Decoding and history tracing is a good to have feature, which is why there is no strict syntax definition. Another reason is that, for many cases, there are ambiguities when doing history tracing. You can't get back the source element even with a strict syntax definition. What we should guarantee is that a model done by an old version syntax will work correctly and can continue modeling with new syntax in newer release. The syntax change may break history tracing, which may affect how good the software can auto fix common topological changing problem. But that's acceptable, as long as it can detect the change and report the failure to user in a meaningful way.

With that in mind, you'll see that TopoShapeOpCodes is just a convenience to centralize all the model operation code. It's exact content is not that important. I prefer to make it in Part workbench, because currently only Part and other workbenches that uses Part make use of it. It is good not to have duplicate op codes, but not a must. So spread the codes in other workbenches shouldn't be a problem either.

[freecadci]

for feature branch PR_8923. Pipeline 813945472 was triggered at f0e9d86. All CI branches and pipelines.

[freecadci]

for feature branch PR_8923. Pipeline 814738102 was triggered at 2aca160. All CI branches and pipelines.

[freecadci]

for feature branch PR_8923. Pipeline 814755132 was triggered at 27a9879. All CI branches and pipelines.

[chennes]

@AjinkyaDahale this looks ready to merge to me -- anything else you want to do before that happens?

[AjinkyaDahale]

@chennes no I think we're fine.