Problems with unique references singleton implementation

[abuts]

ISSUE DESCRIPTION

This ticket addresses two issues: Design flaw and bug. Bug can be actually sorted differently, but still mentioned here.

Simple demonstration illustrates this:

1. fix list option of the container to be able to explore its contents, namely, add return value: glc = glcontainer; to row 862 of the global_references_container code base to be able to explore its contents.
2. clear memory (clear classes, clear all)
3. open _test\test_miltifit\test_multifit_horace_1 and set up break point at row 32, immediatly after Horace loads reference cuts.
4. Run code and stop at break point
5. Do:

>>glc  = unique_references_container.global_container('list','GLOBAL_NAME_DETECTORS_CONTAINER')
    GLOBAL_NAME_INSTRUMENTS_CONTAINER: [1×1 unique_objects_container]
      GLOBAL_NAME_DETECTORS_CONTAINER: [1×1 unique_objects_container]
        GLOBAL_NAME_SAMPLES_CONTAINER: [1×1 unique_objects_container]


glc = 

  struct with fields:

    GLOBAL_NAME_INSTRUMENTS_CONTAINER: [1×1 unique_objects_container]
      GLOBAL_NAME_DETECTORS_CONTAINER: [1×1 unique_objects_container]
        GLOBAL_NAME_SAMPLES_CONTAINER: [1×1 unique_objects_container]

K>> glc.GLOBAL_NAME_DETECTORS_CONTAINER

ans = 

  unique_objects_container with properties:

         n_objects: 24
            n_runs: 24
          n_unique: 24
         baseclass: 'IX_detector_array'
               idx: [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24]
    unique_objects: {1×24 cell}
      n_duplicates: [1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1]

K>> glc.GLOBAL_NAME_DETECTORS_CONTAINER.unique_objects

ans =

  1×24 cell array

  Columns 1 through 4

    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}

  Columns 5 through 8

    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}

  Columns 9 through 12

    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}

  Columns 13 through 16

    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}

  Columns 17 through 20

    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}

  Columns 21 through 24

    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}    {1×1 IX_detector_array}

K>> glc.GLOBAL_NAME_DETECTORS_CONTAINER.unique_objects{1} == glc.GLOBAL_NAME_DETECTORS_CONTAINER.unique_objects{2}

ans =

  logical

   1

There are 3 reference cuts in this reference file, each contains 8 runs with all detector files for each run are the same.

BUG:

unique_reference_container does not count and eliminate unique runs desipite they are equal according to existing cmparison rules. It just adds them together and puts them all in memory.

Due to design flaws described below, this bug should not be fixed on the basis of this very customized singleton implementation. Standard singleton implementation should be implemented and properly deployed in Horace.

DESIGN FLAW DESCRIPTION:
Singleton is a standard pattern in software engeneering. Search "Singleton in Matlab" returns bunch of references, e.g.:

• https://uk.mathworks.com/matlabcentral/fileexchange/24911-design-pattern-singleton-creational
• https://medium.com/@bishikh90/design-patterns-in-matlab-part-1-b0dac5dc9eb7
• https://www.geeksforgeeks.org/singleton-design-pattern/

etc.
They are all rerfer to a bit different implementations which have the same main features:

• static protected storage
• private constructor
• static instance method which provides access to internal storage and methods which interact with this storage.

Using standard code patterns higly improves readability, maintainability and stability of code.

Horace has couple of places where singleton is already used according to the pattern above (e.g. config_store and sqw_formats factory)

unique_references_container contains different implementation of singleton, designed as static variable stored within unique_references_container

This implementation has number of disadvantages:

1. it is non-standard and Horace-specific. When maintainer looks at the code, he/she would not immediately understand what is there and need to read complex custom description on what is this and how to work with it, while any software graduate student is familiar with a standard singleton.
2. The storage and unique_references_contanter are mixed together, despite having different purposes.
3. becauls of (2), methods of "would be singleton" are implemented as a switch over group of keys. This is inferior design in comparison with normal set of class methods, which are visible and easy testable.

The work of converting this custom design into standard singleton implementation is not too difficult and should be performed before doing any modifications to unique references container. I would say that this work is prerequest for doing Re #1781, part 3.

[abuts]

Addressed by Re #1800

[abuts]

Fixed by Re #1800