You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed between Nick and Laurent on Monday 02/06/2008.
The properties need to be able to handle general data values such as chopper speed and angle, but also modifiers to the geometry such as position and rotation modifiers (to account for motors).
The values need to be accessible through the Geometry object, but must not themselves be stored within the instrument tree as we need to share the geometry structure between workspaces that may have different properties.
One possibility would be to have any geometry objects found by through a workspace to be a returned as a throw away object facade that holds a pointer to the object from the geometry tree and a pointer to the relevant properties. This class would only be instantiated from the various data on demand and by using a shared pointer disposed of when no longer needed.
I’ve thought this through a bit more and attached a couple of class diagrams. Broadly The workspace holds a Parameterized instrument, not an Instrument (although they share an IInstrument interface). The Parameterized Instrument is just a composition of the Instrument and a ParameterMap. When you ask a Parmaeterized Instrument for a component you will actually be given a ParameterisedComponent, the main difference is that the Parameterized component has a shared pointer to the ParameterMap.
Within ParameterizedComponent the GetPos, getRelativePos and getRotation methods would be overloaded to check the ParameterMap for any modifications. Also the getParent function would be altered to return another Parameterized Component, allowing a full traversal up the tree.
The text was updated successfully, but these errors were encountered:
As discussed between Nick and Laurent on Monday 02/06/2008.
The properties need to be able to handle general data values such as chopper speed and angle, but also modifiers to the geometry such as position and rotation modifiers (to account for motors).
The values need to be accessible through the Geometry object, but must not themselves be stored within the instrument tree as we need to share the geometry structure between workspaces that may have different properties.
One possibility would be to have any geometry objects found by through a workspace to be a returned as a throw away object facade that holds a pointer to the object from the geometry tree and a pointer to the relevant properties. This class would only be instantiated from the various data on demand and by using a shared pointer disposed of when no longer needed.
I’ve thought this through a bit more and attached a couple of class diagrams. Broadly The workspace holds a Parameterized instrument, not an Instrument (although they share an IInstrument interface). The Parameterized Instrument is just a composition of the Instrument and a ParameterMap. When you ask a Parmaeterized Instrument for a component you will actually be given a ParameterisedComponent, the main difference is that the Parameterized component has a shared pointer to the ParameterMap.
Within ParameterizedComponent the GetPos, getRelativePos and getRotation methods would be overloaded to check the ParameterMap for any modifications. Also the getParent function would be altered to return another Parameterized Component, allowing a full traversal up the tree.
The text was updated successfully, but these errors were encountered: