I'm ignoring the you're working on middleware for the moment.
"data oriented".. what I meant was a metrics based approach. IE actually measuring the efficiency of various designs.
I'd say data oriented is a cache oblivious (or conscientious) approach to data layout based on how data is transformed (access patterns). It also pretty much independent of other design choices..likewise for data driven.
Splitting data from logic at any level of an architecture allows one to focus on how to access it and better organize it for processing.
Sure, nothing to do with component based.
It allows one to query a component manager (CM) / container and get back an iterator over all components stored by their meta-type (all data, all systems).
...and store it in a tightly packed array or perhaps byte buffer or whatever data structure that is the low level DOD form.
Performing a query for something you know. (again ignoring middleware).
The whole component based thing is really rooted in modern "best practices/design pattern-y" think...
Is that a bad thing? For JGO it seems like a poison pill for more than a few.
Yes it's a insanely bad thing. I'm not sure what you're referring to as a poison pill however.
aka every thing you write is a nice reusable generic mini-library. That's the only situation where it makes sense.
Isn't that the promise, traditional OOP in the 90's included, that is sold to management regarding adopting new principles and technology.
The big difference is that the traditional OOP direction didn't deliver on this promise. Implicit CA + EventBus does.
Yeah and the goal of that promise it to service the bulk of programming jobs which is for project with much longer lifetimes than engineer turnover rate. It the most expensive method in terms of both engineering and CPU time but the reduction in risk makes it worthwhile from a business standpoint. But this isn't something to focus on in education or literature because it's roughly the equivant to coding conventions. Anybody that can program can pick it up in approaching zero time.
<snip> This way you can pass structures implicitly between modules without leaking a ton of concrete types and poisoning the larger codebase through unchecked dependencies.
Ok and there are tons of ways to achieve this.
Flip it around into type-think. When in a specific game do you need a type which can contain an arbitrary number of arbitrary types? Answer: never.! When an artist is in control and not a coder.
The game design is in control. Coders, artist and worldbuilder should be in control of their tasks. I don't disagree with any of your bullet points.
For example I frequently have an entity type which can logically contain an arbitrary number of (by name) variables where are logically typeless but are concretely one of a very small number of types (like entity, int, float, string). Data segregation (for data oriented) might be handled by monomorphic access to hide implementation details at the scripting level.
Type safety is handy for many reasons.
In general purpose programming, yes, you want to insure correctness as quickly was possible. However the user here is the scripting side which personally I want to be as fault tolerant as possible. One could go with typed, but I don't since typeless is slightly lower complexity IMO.
I'm curious about the last sentence though regarding data segregation and "monomorphic access" in regard to a scripting interface because the latter is not clearly defined. "Monomorphic access" brings up connotations of immutability or marking classes or accessor methods final. Could you explain this more?
Any instance method which doesn't override anything and is final is monomorphic at all callsites (places in code where it's invoked). The runtime compiler can then treat it as a static method and all optimizations possible for statics are opened up (notable inlining). If not inlined then it's a direct call. HotSpot can optimistically determine if any instance method call is monomorphic. If proved wrong later it will deoptimize. For completeness it also detects bimorphic (exactly 2 versions) and in that case can covert the invocation to an 'if-then-else' construct. Three or more will go through the virtual table.
Don't write middleware if that isn't your product.
Phew, glad this is what I'm doing and is an approved machination.
Of course the rules are different for middleware. I don't talk about that because I prefer the not encourage middleware/library creation.