Will the Observer Pattern make sense for GMSO?

[umesh-timalsina]

In gmso, the core objects are somewhat free form, they have no rules in general. For example you could change any property of any object regardless of its existence in a Topology.

This adds flexibility however, would mean an efficiency hit. For example, lets say you add a Site to a topology, and change its AtomType. Now, if we were to update the topology(adding the site's changed atom type to the Topology's collection of AtomTypes), you would have to go through all the sites to check whether the state of sites changed and apply updates accordingly because with the current Topology API there's no way to observe whether any sites within the topology are in changed state. Same logic applies for any other core objects.

This is an ideal situation for making Topology an observer and Sites, Connections, ConnectionTypes the subjects in my understanding.

For that, I am floating the idea here to start a discussion on whether the Observer Pattern is worth having a look at for our purposes. Specifications like ReactiveX are pretty mature at this stage.

[rsdefever]

Thanks for sharing! This seems pretty neat. A few initial questions come to mind:

• How difficult will this be to implement?
• Will this hurt performance?
• Do we need this capability, or is it 'overkill' for our purposes?
• How will this make future development of GMSO easier (or more difficult)?

I'm sure I'll have more questions, but that's what I have for now.