Feature request: CarbonCopy should use names for references

[chrisb]

CarbonCopy uses the internal numbers for references. When substantial changes are made to the constraints, e.g. the first constraint is removed and another is added, then these numbers change.

If names are used to denote the dimensionals constraints then some very intelligent algorithm replaces the numbered references to names. This works often but not always.

To make CarbonCopy more robust I would like to see the following workflow:
- Create the source sketch, give names to dimensional constraints
- Create a CarbonCopy. If it exists CarbonCopy uses the name, else it uses the number as before.

This would make the model more robust against changes and on top it would be easier to understand the carbon copy if names are used in a sensible way.

What do you think?

ping

[ppemawm]

This would make the model more robust against changes

+1

[openBrain]

Looks nice. As often, I'd agree with this a long as this is an option. Something like "Use constraint names when possible".
If this is unchecked, it behaves as today (reference by index). If it's checked, it behaves as proposed (reference by name if latter exists, else reference by index).

@abdullah : what would you think of renaming "name" with "label" to be consistent with other FreeCAD modules where "name" refers to the internal name (always exists) and "label" refers to the alias given by the user (optional) ?

[abdullah]

CarbonCopy uses the internal numbers for references. When substantial changes are made to the constraints, e.g. the first constraint is removed and another is added, then these numbers change.

If names are used to denote the dimensionals constraints then some very intelligent algorithm replaces the numbered references to names. This works often but not always.

To make CarbonCopy more robust I would like to see the following workflow:
- Create the source sketch, give names to dimensional constraints
- Create a CarbonCopy. If it exists CarbonCopy uses the name, else it uses the number as before.

This would make the model more robust against changes and on top it would be easier to understand the carbon copy if names are used in a sensible way.

What do you think?

ping

Yes. Carbon copy is something I am looking forward to improve.

Please file a ticket.

[chrisb]

Looks nice. As often, I'd agree with this a long as this is an option. Something like "Use constraint names when possible".
If this is unchecked, it behaves as today (reference by index). If it's checked, it behaves as proposed (reference by name if latter exists, else reference by index).

What would be the benefit of using the indexes? I can only think of very artificial use cases. (In case you are in the programming business: using names instead of numbers seems to be similar to moving from assembly code to higher programming languages.)

[Jee-Bee]

an index is also a name...
When the index in the carbon copy have the same index as in the original you have your "names".
But a new sketch start again with 0. In someway there should be a distinction between a carbon copy index and a normal index so it can't interfere with each other...

[chrisb]

The indexes are not CarbonCopy indexes, they are references to the source sketch. And they tell you me nothing about where they occur in the source, unless you I can always remember in which sequence the constraints where added.

[chrisb]

Please file a ticket.

Done: issue #4053

[openBrain]

What would be the benefit of using the indexes?

It works and isn't subject to any user interaction, which is a great thing.
I like names when I myself set expressions, but in the case of CarbonCopy I can't see no real gain (limited to my experience & workflow).
And maybe I like much using numbers.

(In case you are in the programming business: using names instead of numbers seems to be similar to moving from assembly code to higher programming languages.)

Not sure this is a correct comparison, but that's not really a problem.

[Jee-Bee]

The indexes are not CarbonCopy indexes, they are references to the source sketch. And they tell you me nothing about where they occur in the source, unless you I can always remember in which sequence the constraints where added.

I understand that yoe meant the difference in sequence. but that was exactly what i meant is that the index in the carbon copy is exactly the one from it's source.
How to handle the difference (count up from where carbon copy stops; addition on index from carbon copy(cfor carbon and same index as original); etc.) is not up to me.