Symbol storage about brim HOT 2 CLOSED

I'm quite leaning towards creating a separate object as, that would allow a better future proof solution. This object will have the following requirements:

• It must be iterable (M)
• A user must be able to easily retrieve a symbol by name (M)
  • Option would be to either automatically set them as attributes, would be dynamic though.
  • Use __getitem__ to have dictionary like behaviour
• Have a get_description method, which can either take a symbol or a string.

I'm actually shooting this idea, as one can replace the symbols of a body easily. Making a connection between this class and that happening, would make it a SymbolTracker, which seems over complicated.

Maybe I'm actually going for a SymbolCatalog which has a compositional relation towards ModelBase. The SymbolCatalog itself composes of SymbolDescriptor objects, which have a name, full_name, symbol, description and used attributes. It also has a method change_symbol, which is only allowed if the symbol has not been used yet. Here are some quick user stories:

symbols = SymbolCatalog(model_name)
symbols.add_symbol(name, description)  # -> None
symbols.get_symbol_descriptor(name).used  # -> False
symbols.change_symbol(name, new_symbol)
symbols[name]  # -> Symbol(f'{model_name}_{name}')
symbols.get_symbol_descriptor(name).used  # -> True
symbols.change_symbol(name, new_symbol)  # -> raise ValueError("Symbol ... has already been used")
symbols.get_description(name)  # -> description
symbols.get_description(symbol)  # -> description
symbols.get_description(unknown)  # -> None
# How should one add functions and coordinates and speeds

Oh wait, Descriptor would actually be rather confusing.

from brim.

While nice catalog handling would be nice, there are just too many complication due to trees and inheritance. Therefore, the approach is to go minimal and flexible. This means using normal objects like dictionaries. Classes are a bit free in what they like to use. The main approach will be to keep the hard code descriptions property which retrieves symbols and add the descriptions (strings) as values. Other then that it is recommended to use easily accessible stuff like dictionaries: q, u, symbols. Though one is free to also use a matrix or list. For q and u it is sensible to just use matrix, assuming one just uses numbering.

from brim.