This refactors slightly how object types are added to the GUI factory function.
it lets the xml name be defined in the class instead of in the ObjectType.h header, which seems neater.
Taken from D2768
Details
Details
Diff Detail
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 12102 Build 22806: Vulcan Build Jenkins Build 22805: Vulcan Build (Windows) Jenkins Build 22804: arc lint + arc unit
Event Timeline
Comment Actions
Build failure - The Moirai have given mortals hearts that can endure.
Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2433/display/redirect
Comment Actions
I am not sure I like this change... ? I feel like grouping the association between XML names and C++ classes in a single place is neater.
This patch increases the complexity of the macro, so it sounds like we are hiding some code there. We are actually hiding some code by creating a macro with the same name as the actual function, which is very confusing.
IMHO we should not commit this.
This patch adds a new GetObjectType, so I assume this was the original aim of the new code?
Comment Actions
I think it depends on your POV, but I think if we move towards more JS/C++ integration in the future (which sounds like the direction we are taking) it makes sense.
We are actually hiding some code by creating a macro with the same name as the actual function, which is very confusing.
Not sure what you mean here?
This patch adds a new GetObjectType, so I assume this was the original aim of the new code?
It's required in D2768 for the GUI Object to know which factory object to use (since JS objects can now be different for each GUI Object). There are other possible design patterns, ofc.