Do we need unique_name on the base object?

[rozyczko]

This question got recently raised by @damskii9992.

In the EasyScience module it is probably a decent question, since not much functionality depends on explicitly using the unique_name attribute. It is being used in:

• serialization of dependecies (as a backup strategy)
• undo/redo stack
• logger and script manager (of lower importance)

However, it is important to look at implementation in technique-specific libraries as well.

In reflectometry, unique_name is the internal object identifier used to keep ER objects, object-map entries, fitting parameters, and calculator-wrapper storage aligned.
Obviously, it is not intended to be the user-facing display name.
The most important usage is in

1. Backend storage key for refnx/refl1d calculator objects.

The calculator creates backend materials, layers, assemblies, and models using unique_name as the dictionary key in wrapper storage. The refnx wrapper then stores objects under that key in storage['material'], storage['layer'], storage['item'], and storage['model'].

( calculator_base.py L56-L117, wrapper.py L28-L52 )

2. Link between model objects and their calculator representations.

When a model receives an interface, it calls generate_bindings(). Those bindings create the calculator-side objects and attach ItemContainer links so parameter updates on EasyReflectometry objects can update the corresponding backend object.

( model.py L181-L184, calculator_base.py L87-L117 )

3. Disambiguation when multiple layers/materials have the same display name.

User-facing names can repeat, but backend IDs must not collide. Constructors generate a new unique_name when one is not supplied, so two objects both named SiO2 layer can still be distinct internally.

( material.py L57-L58], layer.py L65-L66, model.py L81-L82)

4. Prefix source for parameter IDs.

Parameter unique names are derived from the owning object's unique_name, for example f'{unique_name}_Thickness' or f'{unique_name}_Sld'. This makes individual parameters identifiable across fitting, serialization, summaries, and posterior analysis.

(layer.py L69-L80, material.py L60-L72 )

Thus, in reflectometry, removing unique_name would require a significant amount of refactoring.

[henrikjacobsenfys]

I don't think I need unique_name, but I don't mind it being there. Removing it would not be a big deal for me, as I'm anyway going to move to name soon.

[AndrewSazonov]

1. EasyScience

You mentioned that unique_name is currently used in:

• serialization of dependecies (as a backup strategy)
• undo/redo stack
• logger and script manager (of lower importance)

What exactly does “as a backup strategy” mean here?

How undo/redo stack is planned to be handled if unique_name is removed?

2. EasyDiffraction

In EasyDiffraction, I do not use unique_name from EasyScience.

The unique_name values used in diffraction are built from the full parent-child path and are CIF-oriented. For example, I can have two atoms with the same label, such as Co, but only if they belong to two different structures, for example coo and lbco.

In this case, the corresponding unique names would be:

• coo.atom_sites.Co
• lbco.atom_sites.Co

This gives me a natural way to serialize and deserialize data to and from CIF. It also makes debugging much easier because the names remain meaningful and domain-specific. For me, coo.atom_sites.Co and lbco.atom_sites.Co are way more readable than generic names such as structure_1_atom_1 and structure_2_atom_1 or even just atom_1 and atom_2.

So, for diffraction, a non-CIF-based generic unique_name is therefore not really useful. Since a CIF-oriented identifier is used anyway, having both a generic unique_name and a CIF-oriented unique_name at the same time may be confusing.

[seventil]

As far as I remember from previous discussions with @damskii9992 , the use-case for unique names were developer preferences towards how they want to reference parameters.

[AndrewSazonov]

The undo/redo stack is broken anyways and due for a rewrite (as far as I am aware).

Are we sure that unique_name will not be needed when fixing or rewriting the undo/redo stack?

My concern is that if we remove unique_name now, we may later discover that undo/redo still needs it, and then we would need to reintroduce it again.

[damskii9992]

My concern is that if we remove unique_name now, we may later discover that undo/redo still needs it, and then we would need to reintroduce it again.

That is a very valid concern. Is it worth the maintenance cost of the unique_name though? We've already spent so much time fixing and understanding this piece of code. And butting our heads against a wall trying to use it smartly.

[rozyczko]

That is a very valid concern. Is it worth the maintenance cost of the unique_name though? We've already spent so much time fixing and understanding this piece of code. And butting our heads against a wall trying to use it smartly.

Removing the feature is easy. Adding it again, when we realize we really needed it, is going to be more demanding.

The current way of creating and maintaining the core model <-> calculator model relationship and mutual parameter updates in tech specific libs is based on unique_names (in reflectometry (as mentioned) and used to be in diffraction)

We might spend time on rewriting this in a way that doesn't require creating a separate calculator model, but do we want to?

[seventil]

undo-redo redesign seems to be the bottleneck here