...
(Rob) Perhaps we could leave this to specialised high performance versions of IValueSet? 
(Gena) The use of interfaces without methods / properties is a very bad code smell AFAIK. If we introduce IValueSet and define it as a generic way to access values - it should provide way to do so.
...
(Jesper) Alternatively these can be implemented once and for all as C# extensions, which will be able to utilize high performance implementations, but does not require to be a part of the public interface.
Meeting Decision: All agreed to leave this out of the IValueSet for OpenMI 2.
IExchangeItem event
(Gena) What is our goal with ItemChanged event in IExchangeItem? Do we want to get this event fired only when values of the exchange item are changed? If yes - then let's rename it to ValuesChanged and add indices to it (indicating which values were changed). That should make it much more useful.
...
(Rob) I have updated the method name in IBaseExchangeItem as follows :
| Code Block |
|---|
/**
* Returns an Observable to be used to receive notifications from the
* exchange item about content changes. This notification is sent when
* the exchange item values have been updated. It is the responsibility
* of the observer to figure out which actual values have changed and
* how to act on these changes.
*
* The argument passed in the Observer update call must be an instance of
* the ExchangeItemValuesUpdatedEventArgs class.
*
* @return Observable for receiving exchange item change notifications
*/
public Observable getValuesUpdatedObservable();
|
Also renamed the event args class to: ExchangeItemValuesUpdatedEventArgs .
Meeting Decision: All agreed to this change, the C# code will be updated accordingly. It was noted that some additional events / notifications should be added to the ITimeSpaceExchangeItem for changes to the time set and element set.
Namespaces for interfaces
...
(Jesper) I would then probably make a spatial/geometry namespace or similar, that holds the ISpatialAxis, IElementSet, and the future ISpatialLine or whatever types of geometries that are required to be supported. Because most likely the TimeSpace version is not the only type of component that requires a spatial definition.
Other issues
Meeting Decision: Agreed to create the timespace namespace and put relevant interfaces there. Base interfaces are to be put in the root (standard) namespace.
Other issues
- ((Peter) What happens if MyDictionaryComponent gets linked to MyLinkableComponent? Does one class have to derive from both extensions? (MyLinkableDictionaryComponent : IBaseLinkableComponent, IDictionaryComponent, ExtensionTimeSpace) Is there more than we can properly think through in three weeks?
...
(Jesper) When it implements the IBaseLinkableComponent, then it is OpenMI 2.0 compliant. The rest is in principle up to adaptors. We could consider to require that components also specify which extensions it supports, i.e. a 2.0 TimeSpace component is base compliant and time-space-extension compliant.
Meeting Decision: Adrian pointed out that with this support for extensions we should be more clear about what compliancy means. Even with OpenMI 1.4 it is not clear to a user what he can expect when a model is OpenMI compliant. We agreed to work on a better definition of OpenMI compliancy and add it to the documentation.