Okay you’re right, the idea of “later on we can revisit” is risky since it’s almost 100% guaranteed that no revisiting will occur.
There have been two times that I’ve tried to take someone’s code and reform it into the structure I think is best. From this, I have decided that the best workflow is:
(1) Create/brainstorm/prototype your new design separately from whatever already exists.
(2) Implement your design by morphing the existing code into what you want.
The reason for this is that I think you will end up with a subpar design if you start out with the constraints of the existing system. Also, I find it very hard to think about the new design clearly if I’m constantly bogged down with thinking about how it’ll tie in.
The reason for (2) is that it’s unreasonable to start the project from scratch; the only reasonable way to implement something is incrementally, and that’s why it’s important to start from what exists.
One reason I suggested Sahil’s option 1 is that I thought it sounded similar to what we had discussed in 2013 when I started working on that linkage module: a higher level API that simply used the lower-level API. I’m a little too far removed from Sahil’s project to know exactly how his project fits in, though.
For users, I think it’s also useful to have two very conceptually distinct API’s: the traditional symbolic API where you write the velocities of points and bodies explicitly, and the traditional numeric/tree-hierarchy API (simbody, physics engines, etc.). If both uses are in one API and the distinctions aren’t clear, it might be really difficult for me to understand as a user.
It seems like some prototyping may be necessary to see if Sahil’s option 2 is viable. That is, write an example file that assumes the additional Force, Joints, Constraints classes that are just additional to the current interface, and see if it’s clear.