I didn't realize we'd defined accessor to imply a function. Operator-> is an accessor that I would need to parse in, instead of using the implicit this->. Assuming there is no function (which would be necessary in some cases), the push is dropped.
Once again, the need for specific combinations in the tier system is not a problem for flexibility simply because there is no other order the tier system could operate in. I failed to understand this when I opened this for discussion. Adding, for example, a "z" variable to the "planar" tier makes it no longer a "planar" tier; it doesn't make sense for the lower tiers to inherit from it, as the lower tiers are intended for access by a system designed around the game being 2-Dimensional. Having a component for this won't matter; it'll just change the position of the "`z' is not a member" error if a source file tries to access that local. I don't see any amount of flexibility; changing a lower tier for any good reason implies a need to change the systems inheriting from them. Find a counter example instead of screaming "Flexibility" and I might consider what you are saying.
Also, understand that in this discussion, my arguments are never in vain. I am the only one coding for this project; that's the sad fact about it. Our friends at Canonical recently asserted, "This isn't a democracy." Granted, that's an assholish move, but that's what it comes down to. You have the burden of proof, always, because I'm coding. You are the one that needs to enumerate plenty of examples of where your system outperforms mine. "Flexibility," as a general term applied to nothing, doesn't count.
I've made large changes in the past when someone has provided a genuinely better idea; usually the fact of the idea being better has been obvious, but I know Luda threw me at least one instance where that wasn't the case. As it stands, each tier uses variables from -every- inherited tier. Meaning recompile rates for the systems would be the same anyway if, for example, the type of "x" was changed from "double" to "int." I in fact see no gain with respect to recompilation from using a component system, except in the case that you are only -adding- to a specific component, and each component is tiered itself. That's a decent-sized if, not to mention that I'd consider that an ugly system.
Moreover, a component system for a number of wild, so far unconceived systems can easily be added as a bottom tier, anyway. Not that I can name such a system. A simple variable could be used for bottom_tier_size to skip to the end of the essentials and locate such a system.
What you need to see is that the undefined residuum of flexibility you claim the component system offers is inapplicable to the lower tiers. The -first- instance of a tier that does not depend on every lower tier would be the path tier, which needs to implement path_index but does not need access to the collision tier nor the graphics tier. In this special case, bottom_tier_size would be valued as sizeof(collision_tier) if the graphics and collision systems are in use, or just sizeof(planar_tier) otherwise. There, it would perhaps be logical to implement a component system, which would take up, in itself, 33% of the space used if no component system existed (or 50% on 64 bit systems). The hope would of course be that as more components emerged (which doesn't seem likely), the system would pay for itself. Regardless, there's a lot to consider as far as what is hard coded.
|