[WIP] Subclassing OpenSim classes in Python

[chrisdembia]

I reproduced something that @aymanhab did a few months ago: subclassing an OpenSim class in Python and using it with a tool. OpenSim can recognize the new class, etc. I think @aseth1 and @klshrinidhi have expressed interest in this.

If we want to be able to do this, there is still a lot to iron out. It'd be nice if we could register this type (OpenSim::registerType()), but I'm running into memory ownership issues there; perhaps @aymanhab would know how to address such memory issues.

---

This change is 

[aymanhab]

@chrisdembia Nice job indeed, I was planning to add a "Controller" instead but the same process holds. We'll have to decide what classes we should allow extending since there's a cost in code bloat due to SWIG directors. I don't think RegisterType is necessary (although possible) since that only plays into registration and XML serialization which shouldn't be needed for development/prototyping purposes.

What symptoms of memory problems did you run into? I saw nothing on AppVeyor, testComponents fails for an unrelated reason AFAIK.

[chrisdembia]

What symptoms of memory problems did you run into?

Segfaults. I didn't try too hard to understand what was happening. It'd be good to discuss in person.

I also tried making a custom ModelComponent. I was able to implement a protected method but I was unable to call protected methods from it! This could present serious problems!

I agree that serialization/deserialization is not necessary; it would be nice icing on the cake though if we could get it to work. It'd be neat if we could give python users an equivalent of OpenSim_DECLARE_PROPERTY. I think it may be possible.

[aymanhab]

@chrisdembia Thanks, why don't you add the code that causes the segfault as a test case so I can reproduce and we can discuss and make sure it stays fixed.
As you pointed out the Property macros is another big hole that we'll need to plug if we're to allow the extensions to have Properties, we should discuss in person.

[chrisdembia]

why don't you add the code that causes the segfault as a test case so I can reproduce and we can discuss and make sure it stays fixed.

done

[aymanhab]

Awesome, thanks a million @chrisdembia

[aymanhab]

@chrisdembia Thought I'd document my findings and status of this PR since I spent some time on the investigation:

1. The test case now has a working example of an Analysis written purely in Python that is executed during a forward simulation. That's a significant accomplishment, likely 80-90% of use cases.
2. The cases that use "clone" rather than adopt fail and are worse examples for educational/practical purposes since you don't have access to the actual Analysis and awkward way to get a handle to it anyway due to the safeDowncast issues even if it worked. Anyway, clone fails for the following reason(s)

• Base class Analysis is Abstract, SWIG by default doesn't wrap/expose Abstract classes (unless we use noabstract feature).
• The clone method uses covariant return types, these were not supported for a while in languages other than C++ and as of now are not supported in SWIG even though they are in Java.

I can think of solutions around these issues (e.g. create non abstract class in the interface file that we can wrap/expose and have that as base classes e.g. PythonAnalysis etc. but that may complicate documentation etc. and will need to scale to other Components) Considering how we're handicapped by using Macros for Properties it probably make sense to stop here until there's a specific use-case/need, but let me know if you think otherwise.

[chrisdembia]

1. The cases that use "clone" rather than adopt fail and are worse examples for educational/practical purposes since you don't have access to the actual Analysis and awkward way to get a handle to it anyway due to the safeDowncast issues even if it worked.

I don't think we should support users calling clone(), but the rest of OpenSim may call clone() on the user-defined class (e.g., for registration). Thanks for investigating this. I agree that creating PythonAnalysis, etc. is a last resort. I think we should be able to come up with a way to implement clone() in python using the decorator. Perhaps we could sit in front of a computer together and look at the problem further?

I think we could find a workaround for properties using python decorators, so long as the addProperty methods are available (we'd have to create template instantiations, e.g., addOptionalPropertyDouble, ...). This would be fairly limiting (the available types for properties would be preset), so maybe it's not worthwhile.

[chrisdembia]

@aymanhab , I updated this.

[aymanhab]

@chrisdembia Aside from the implementation of clone, this seems working now. Haven't touched the ModelComponent issues/tests but maybe similar fix (where base class methods that are used need to be declared as director methods). Please take a look when you have a chance. An example in Java with a pure implementation of clone in Jva is working perfectly as well.