Collections based on ModelBase

[rozyczko]

This is the collection list as described in #226
Rebased against the new develop branch and due to the number of files affected, made a separate PR.

For discussion look in: #226

[rozyczko]

Another question:
Currently, the code allows backward compatibility, so old Parameter and Descriptor objects can be used alongside the new ones based on NewBase.
Does it make sense to keep this compatibility layer for the interim process or should we completely forget about ObjBase derived classes?

[rozyczko]

Another question: Currently, the code allows backward compatibility, so old Parameter and Descriptor objects can be used alongside the new ones based on NewBase. Does it make sense to keep this compatibility layer for the interim process or should we completely forget about ObjBase derived classes?

I don't think it makes sense to carry over functionality which will be removed in the next release.
Removed all vestiges of BasedBase dependencies, inclusing methods for backward compatibility with the old ModelCollection.

[henrikjacobsenfys]

This may be a stupid question, but shouldn't this inherit from or use EasyList? There is at least some duplication of logic.

Otherwise a handful of nitpicks and questions to consider.

[henrikjacobsenfys]

If display_name and name are both None, then self._name is also None. Is that desired, or should there be a fallback?

[rozyczko]

I don't thing this is an issue. When name is None, self._name falls back to self.display_name, which in turn falls back to self.unique_name (auto-generated) in new_base.py: 83-86. So _name is never None.

[henrikjacobsenfys]

Is that actually desired behavior? I would think that people want to keep name and display_name separate?

[rozyczko]

This is intentional. The constructor already syncs them (if display_name is None and name is not None: display_name = name )
The setter keeps them in sync for consistency. If a user explicitly sets a different [display_name] via the constructor, the two diverge until name is set again.

This could be revisited if use cases emerge where they need to stay independent after initial construction.

[rozyczko]

This may be a stupid question, but shouldn't this inherit from or use EasyList? There is at least some duplication of logic.

CollectionBase inherits from ModelBase (which provides parameter aggregation, get_all_parameters(), get_free_parameters(), etc.), while EasyList inherits from NewBase.

EasyList is a pure typed container. It holds a flat list of NewBase items in _data, enforces protected_types, and provides list operations + unique-name lookup. It has no awareness of models, parameters, or fitting — it's essentially a list[T]with type safety and serialization.

The new CollectionBase is a model-aware collection. Inherits from ModelBase and gets the full parameter aggregation API (get_*_parameters), running recursively. It also adds name, display-name lookups, and can have its own deserialization. This means a CollectionBase can be directly used in fitting.

[henrikjacobsenfys]

Looks good to me now

[damskii9992]

Pretty sure you are making this CollectionBase needlessly complicated. It is considerably less code to simply inherit from EasyList, overwrite the default protected_type to ModelBase rather than NewBase and then just implement the get_all_variables methods.

It should also be much more maintainable. We might need to make the class also inherit from ModelBase just to make sure it is registered as an instance of a ModelBase class, but since you overwrite all the methods, it would only be for type-checking.

Also, why does the class even have a name attribute? Didn't we want to get rid of that?