Does the method Component::getSystem() need to be public.

[aymanhab]

While trying to SWIG wrap the new class OpenSim::Component (needed since it's a base class for ModelCompoenent) I ran into the public method

/**
* Get the underlying MultibodySystem that this component is connected to.
*/
const SimTK::MultibodySystem& getSystem() const
{ return *_system; }

which wraps into an unusable method since SimTK::MultibodySystem is not SWIG wrapped either and so it is impossible to use in scripting.The main question is whether this method should actually be protected (and so will be removed from wrapping) or if the SimTK::MultibodySystem is used more across the API and will need to be wrapped for scripting purposes.

[aseth1]

Out of curiosity, what are you doing about:
const SimTK::MultibodySystem& getMultibodySystem() const

It seems redundant now that the base component supports access. I hadn't planned to make it protected since it is very useful to access the MultibodySystem in order to leverage the Simbody API. I am not sure why this as a core-API issue.

[aymanhab]

@aseth1 @sherm1 I'm doing nothing about getMultibodySystem() either, and it's a problem as well.
In the past I enclosed these kind of methods in #ifndef SWIG so that methods available in Scripting/Matlab are all meaningful, but that pollutes the headers and introduces differences cross language.

Bottom line is, either these SimTK classes are necessary then I can try to wrap them thru SWIG, or they are not (only intended for some low level computations) and then they can be hidden from the interface.

[aseth1]

There are only 7 use cases of getSystem() and only 2 of them are not within the Component itself and are being called on a Model. In that case these could be changed to getMultibodySystem() on model and Component::getSystem() made protected. That might actually be a good thing.

The bigger issue, however, is that there are 78 calls to Model::getMultibodySystem() and for some of them there are model methods that have been added (e.g. for CoM kinematics) but many others are for forcing the realization stage and performing customizations like adding handlers and constraints. I don't want to overload the Model with these capabilities. I think public access to the MultibodySystem does allow users (albeit advanced) to utilize the Simbody API directly keeping the OpenSim API lighter. If we want scripting to be at par with C++ programming we will need to wrap the MultibodySystem.

[jenhicks]

Should be public, but hide from Matlab (i.e., don't wrap).