I read most of the documentation but have limited time so I skipped a few of the last pages. Here are my notes so far: 1. The introduction page would benefit from having a short but demonstrative example before or after the list of features, but surely before getting into "comparisons". 2. There is another meaning of mixing that is D mixin, which I believe is highly differnt, but maybe a mention to clarify that it's different would help someone used to D. 3. You are talking about mixins in Ruby without a short description of what it is or any link to an explanation. 4. The introduction page have a lot of assertions about the performance of the library but no link to a page with performance comparisons. I also don't see one in the index. I would like to see one. 5. I'm not at ease with the macro defining the mixins and messages, but I'm guessing it would be hard to do otherwise... 6. In the basic example, you forgot to specify that the namespace is boost::mixin. 7. Can the definitions be inlined so that a header-only library can be implemented using boost::mixin? 8. I'm not totally sure but I find the basic example maybe a bit more complext than it could be. That's only intuition though, I don't have a specific suggestion. Yet. 9. I think I mentionned in the previous Boost.Mixin thread that I would like to have a simple way to process the full range of mixins of the same type, ignoring which objects they are "attached" to. However I don't see that feature in the documentation. The messaging system don't exactly match what I'm asking and I expect that if the user knows the exact mixin type to process it would be faster to just go through all the mixin and do the processing on each instance. This of course, assume that the mixin objects are stored "somewhere" together, per type. 10. When dispatching a message to a sequence of objects, depending on the object's mixins, it will or not do something. I would like to see a comparison of performance between messaging objects which have at least one mixin reacting to the message VS objects which have no mixin reacting to the message (but do have mixins). Basically I'm wondering if messaging cost is lower when there is no actual message handler in the mixins of an object. If not, this limits messaging to events processing (which is fine), but makes it almost impractical for mixin state updating (which is the what I want to do in [9]). 11. So far I don't see the usefulness of message priority. Could you give a demonstrative example? 12. It is not clear to me why there is need for a separate macro for const messages. 13. I feel like your game example in Tutorials is a bit flawed. For example, you use mutation to change the behaviour of the ennemy, but in the next section you explain that mutation is a slow process. Basically, that's not convincing, no game dev would do it like that I believe. However, it's only the example that is not convincing, not the principle. 14. `object_type_template` seems very important but there is no section explaining what it is and how to use it until in the middle of the second Tutorial. --- I skipped some of the pages. 15. In the Appendix you explain what an ECS is, but it's uncomplete and don't explain all the benefits. There are different types of ECS: a) component types inherit from a base type, components instances are contained/owned by the entity instance; b) same as a) but components are actually gathered in arrays by types, entities instances only have references (pointers or something else) to component instances; c) entities are just ids, components have ids, so an entity is defined by all the components having the same id; (of course there are variants of these setup) The a) solution is simple to understand. However it don't have the efficiency benefit of b) where components are gathered in arrays which are efficient to traverse with an update function (which is essential for efficiency in games). The c) solution might seem a little extreme but is actually the best way to benefit both of efficient traversing like b) and from concurrency (if you manage to have components that are truely independent) as several batches of components can be processed concurrently. Actually, c) is used in major console game engines, like the one from Naughty Dogs (Uncharted for example). The efficient processing of components is not part of your description in the ECS section, which is a problem as it is one of the two actual reasons why the ECS is actually interesting for any kind of simulation (the first reason being that it helps changing easily behaviour of entities when developing the content of the software - the composition can easily be scripted, no need to have people designing the content having to code to compose the entities). (I recommand this book[1] which have a whole chapter about this, and explains better why ECS are used in games than most of the sources I read in Further reading section.) I'm not sure what Boost.Mixin actually implements here, but if it's neither b) nor c), I would consider it unpratical in most action games. As a side note: If there is a way to achieve processing an array of components as one batch, then I would like the container of components to _not_ be global (maybe optionally), so that if I use it, I can separate the processing into several "world sections" that can be processed separately. [1] http://www.gameenginebook.com/