should OpenSteer use mixin classes?
Status: Alpha
Brought to you by:
cwreynolds
Menu
▾
▴
Starting a new thread regarding the use of mixin classes in OpenSteer. This post is a response to https://sourceforge.net/forum/message.php?msg_id=2783623 -- see also:
https://sourceforge.net/forum/message.php?msg_id=2778129
https://sourceforge.net/forum/message.php?msg_id=2778333
https://sourceforge.net/forum/message.php?msg_id=2783565
BK: ...Concerning mixins...in the "SimpleVehicle.h" header, a local space is inherited (by mixin) from an abstract vehicle which I personally find a bit strange from a design perspective (though I understand the ratio behind it)...
I would describe SimpleVehicle as a mixture of three component classes (LocalSpaceMixin, AnnotationMixin and SteerLibraryMixin) plus its own implementation of the AbstractVehicle protocol. The typedefs for those "precursor" classes (SimpleVehicle_1, etc.) which layer the mixins together -- and the clumsy template-based syntax -- all detract from the conceptual simplicity of the idea.
The syntax you cited looks cleaner. I will have to learn more about it. If it provides the same functionality I'd be happy to adopt it. To me the key is not mixing protocols, but mixing *implementations* of protocols. LocalSpaceMixin adds "local space functionality" to whatever it is mixed into (currently SimpleVehicle and the concrete LocalSpace object which is used in a few places to store a transformation value).
BK: ...Why can I use [SimpleVehicle] where I can use an abstract vehicle - and why is an abstract vehicle a local space?...
I'm not sure exactly what you are asking but: the result of this class mixture is that "is-a" both vehicle and local space -- it has the state and capabilities of both. This is similar to saying a vehicle "has-a" LocalSpace object. The difference is that with a mixin the member functions are inherited by the vehicle itself so you don't have to keep track of which subsubcomponent object of which subcomponent object supports the function it needs to call. My philosophy is that a vehicle has (say) a forward direction. The more common approach in C++ is that a vehicle has a component called a LocalSpace and a LocalSpace has a forward direction.
Hi all.
Some thoughts of mine about the ongoing discussions about the mixin's and the redesign plans:
About the mixins:
First, I have to admit, that I have seen mixin templates never before I had a look at OS (like the already mentioned 99%) and I don't think that I will ever use them myself. But, whether I/99% like/know them or not is not really the point here: Getting rid of the mixin structure would cause a rewrite of a lot of working code, and I think that there are tasks that are more important. And in addition, I think that most users don't have to bother with mixin anyway. If it ain't broken, don't fix it!
I think there should be rather some type of a ready to use class (with localspace, abstract vehicle and steering mixins, almost like SimpleVehicle) with a clean interface, that has no OpenSteerDemo (or OpenGL/Drawing/Annotation etc) related function calls in it. That's the way I'm using OS with OpenSG (www.opensg.org) here, and after I integrated it once, I never had to worry about the mixins again (_very_ glad about that, though).
Well, and if we talk about ready to use here: For the same reasons, I would suggest to move all the classes that have something to do with drawing (like Annotation for example) to a seperate OpenGL/ and the SimpleVehicle as well as the OpenSteerDemo to the src/ directory. The OpenSteer/include directory should only contain classes, that have nothing to do with drawing or the demo. In addition there could be something like an OpenSteerEnvironment, that provides the core functionality by holding a clock, the proximity db, obstacles and updates all the associated brandnewreadytouseclass-Vehicles every frame. I realized this one as a Singleton object that is accessible everywhere by a OpenSteerEnvironment::the()->doSomething(). I will clean up mine and put it on my website, maybe this could be a starting point.
Just my 2 (Euro)-cents,
regards,
Dominik
>I will clean up mine and put it on my website, maybe this could be a starting point.
Not as clean as I wanted it, but it should be sufficient:
www.uni-koblenz.de/~dominikr/OpenSteerEnvironment.h
www.uni-koblenz.de/~dominikr/OpenSteerEnvironment.cpp
Regards,
Dominik
Sorry, wrong links:
http://www.uni-koblenz.de/~dominikr/opensteer/OpenSteerEnvironment.h
http://www.uni-koblenz.de/~dominikr/opensteer/OpenSteerEnvironment.cpp
Regards,
Dominik
Ahem,
I shouldn't do this on sunday mornings. Third try:
http://www.uni-koblenz.de/~dominikr/opensteer/opensteerenvironment.h
http://www.uni-koblenz.de/~dominikr/opensteer/opensteerenvironment.cpp
Regards,
Dominik
During our recent talk about mixins, it slipped my mind that this topic is touched upon in the OpenSteer 0.8 documentation (http://opensteer.sourceforge.net/doc.html#Integrating). It claims that OpenSteer functionality can be used in both IS-A and HAS-A architectures. That claim would be more plausible if a sample of the latter were provided. Perhaps one of the plug-ins should be written in HAS-A style, with OpenSteer objects living inside the objects of a fictional game engine.