Re: [simspark-devel] APL Completion

[Hedayat V. <hed...@ai...>]

Hi Andreas,


On ۱۰/۰۱/۱۵  03:01, ah...@un... wrote:
> Hello,
>
>
> To "celebrate" the completion of the abstract physics layer, I wrote a
> small paper that exmplains all my design choices and detours I had to take
> during the implementation. It will serve as the foundation for the thesis
> I will have to write on this, but is currently not very well-written. I
> would greatly appreciate it if anyone could take some of his time during
> the weekend to read this, and give me any kind of feedback!
>
> http://www.uni-koblenz.de/~aheld/APL_Paper.pdf
>    
Conguratulations! :)
Thanks a lot for all your efforts in developing the APL.
I have a few comments regarding the paper and also your recent commits.
1. (This might be out dated with regard to the recent commits) About the 
Implementation classes: In the paper, you've said that some classes have 
2 instances of their parent implementation class (e.g. SphereColliderImp 
has two instances of ColliderImp class): one of them through direct 
inheritance and another one inherited from the Collider class. My 
suggestion is to eliminate the inherited one and use the inherited 
Collider instance instead (as it functions as a gateway for the internal 
Implementation class) or get the Implementation object of the Collider 
class if the implementation object itself is needed and the 
functionality is not provided through the Collider class (I might have 
missed some points as I'm not aware of the code very much).
It seems that you've changed the design and now there is only one object 
of each Imp. class globally. If it is possible (so the Imp. classes 
probably doesn't have any variables), so this is a good solution too. :P 
And their case will be similar to the case of static functions 
(explained below).

2. The Static Functions: if I've understood correctly, there are a set 
of static methods with engine specific implementation. Instead of having 
a class with different implementations based on the selected physics 
engine, my proposal is to either use a single object of an engine 
specific implementation and call its member functions (the object 
reference can be obtained from either from the Zeitgeist framework or 
having a static GetSingleton() function in the StaticMethods class), or 
by using the bridge pattern for the StaticMethods class too: this class 
could have a static private refrence to an implmentation class which is 
used by the static functions.

3. In your recent commit, you've introduced a factory class which 
currently contains the instances of Imp. classes. I've two comments 
about it: first, the same pattern have been used throughout the code but 
with a slightly different style: references are stored in the zeitgeist 
hierarchy and accessed using its methods. You might use the same style 
for more consistency (or might not!).
Second, the instance of the factory class itself is usually obtained 
using Zeitgeist framework too, instead of calling a static method like 
TheFactory::GetInstance(). Beside from consistency point of view, this 
style provides the flexibility to create the desired object in .rb 
scripts (the actual engine is selected there). (Notice that I've NOT 
checked to see where you create the actual factory instance, so your 
solution might be as flexible as this one!).
Also you could use this factory to create any engine specific objects 
and not only storing single instances (but apparently you do not have 
any such engine specific classes and all of them are single instance 
classes?!).

Finally, I feel that you are reaching a point where you can completely 
detach the ODE specific code into a separate plugin rather than being in 
the Oxygen library itself. This would be nice! :)

Thanks a lot,
Hedayat



> thanks,
>
> Andreas
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>