ADR Suggestion Getting rid of the BaseObj class

[damskii9992]

General

The current codebase have 3 different base classes: BasedBase, BaseObj and BaseCollection. BaseObj and BaseCollection inherits from BasedBase and adds the functionality to dynamically add attributes and methods to instances of the class during runtime.

Due to confusion regarding which of BasedBase, BaseObj and BaseCollection is the actual base class to be inherited from, currently our objects have a mixture of inheriting from them. This confusion needs to be addressed by solidifying what our baseclasses are actually supposed to do.

Current implementation

As mentioned, we currently have 3 "real" base classes BasedBase, BaseObj and BaseCollection:

The BasedBase class

The BasedBase class inherits from ComponentSerializer which allows the object to be serialized and deserialized (i.e. saved and loaded). It implements 5 generic attributes: global_object, unique_name, name, interface and user_data.

Attributes

The global_object is a reference to the BORG class global_object holding a map of all the generated easyscience objects (see #29)
The unique_name is the objects own unique identifier in the global_object
The name is the name of the object, used when printing if there is no "display_name" or other fancy name attribute.
The interface is an optional reference to an Interface object. Default is None. Appears to be deprecated and unused.
The `user_data´ is a dictionary which appears unused

Methods

On top of the regular setters and getters, the BasedBase class implements the following methods:

def generate_bindings(self)

Generates or re-generates bindings to the interface. Appears deprecated as we no longer use this interface template.

def switch_interface(self)

Similarly switches the interface to a new interface. Also appears deprecated.

get_parameters(self)

Returns a list of all Parameter objects in the object. This functionality should not be in a base class.

constraints(self)

Returns a list of constraints of all Parameter objects in the object. This functionality should not be in a base class.

_get_linkable_attributes(self)

Returns a list of "linkable"?`attributes. Not sure what this method is even supposed to do.

get_fit_parameters(self)

Returns a list of Parameters which are not fixed. This functionality should not be in a base class.

__dir__(self)

Is apparently implemented for auto-completion only? Not sure if this is needed or not.

__copy__(self)

Defines how the object is copies. Is necessary due to the unique_name being an unique identifier.

___reduce__(self)

Makes the class pickable. Is apparently needed for serialization? Possibly not actually needed.

The BaseObj class

The BaseObj class inherits from BasedBase and introduces no new attributes. Instead it allow for *args and **kwargs to be passed to the constructor, which are then checked against existing attributes and then added as attributes to the object with the AddLoggedProp function from easyscience.Utils.classTools.

To facilitate dynamically adding attributes to the object, the base class contains the following methods:

_add_component(self, key: str, component)

Hidden method which uses the AddLoggedProp to add the attribute to the Logger and to the global_object.

___setattr__(self, key: str, value)

Includes all the logic to add the attribute

___repr__(self)

Handles the printing of the object. Should be in the BasedBase class.

@staticmethod
___getter(key: str)

A wrapper to wrap the normal getter method for the dynamically added attributes. Not sure why this is needed, if at all.

@staticmethod
___setter(key: str)

A wrapper to wrap the normal setter method for the dynamically added attributes. Also not sure why this is needed.

The BaseCollection class

The BaseCollection class inherits both from BasedBase and MutableSequence. Seems like it is meant to be identical to BaseObj in that it allows for dynamically added attributes, yet is implemented as a python collection with the relevant ___getitem___, __setitem__ and __delitem__ etc. methods.
This class might have some raison d´etre (reason for existing), but I am unsure of what. Custom collections certainly makes sense, but do we really need a baseclass for those?

Proposed Implementation

I propose to remove all functionality for dynamically adding attributes to objects. The only possible users I can envision are ourselves and using dynamic attributes simply makes code harder to read, write and maintain.

I also propose to remove the deprecated features from our baseclass, which is the interface methods and Parameter related methods.

Removing dynamic attributes

Specifically I propose to entirely remove the BaseObj class and rename the BasedBase class to BaseObject. Truly making it the base class of easyscience.

For BaseCollection I propose to remove it entirely, unless it is actually needed in which case I propose to simply remove the functionality for dynamically adding attributes.

Removing interface methods and attributes

It was decided in https://github.com/orgs/easyscience/discussions/29 that the Calculator (which is currently known as interface) should be constructed by a calculator factory and belong to the Analysis object. If other objects needs access to the calculator, they need to reference the Analysis class. As such I propose removing the interface functionality from the new base class.

Additionally, if it is truly deprecated, which I believe it is or will be, I propose to remove the InterfaceFactoryTemplate and the entire file interface.py.

Removing Parameter methods from the base class.

While having generic functionality to go through child-objects to generate a list of Parameters in an object is surely a useful functionality, it only belongs to objects which are part of the SampleModel or InstrumentModel classes. I.e. it is not a functionality which should exist in the base class of easyscience. As such I also propose to remove those.

[damskii9992]

It was discovered that the mandatory name attribute of Parameters, Descriptors and BaseObjs could not simply be removed due to it being the key used to get the attribute when automatically injected in BaseObjs.
As such, the name attribute cannot be removed before object injection is removed, i.e. before the current BaseObj is removed.
Once this is done, the removal of the mandatory name attribute should be revisited, as it is not a desired attribute.