Item better config extraction and parsing: move to PyDantic classes
Closed this issue · 4 comments
Moving Items class to pydantic's BaseMode allow for in-place validation of item paramters, which removes any if all self-written validation boilerplate.
PyDantic has issue with properties (setting, and serialising):
pydantic/pydantic#3395
pydantic/pydantic#935
PR with feature-request: pydantic/pydantic#2625
Current proposition is that any property attributes could not be set:
ValueError: "StarshipHull" object has no field "armor_models"
make: *** [Makefile:9: start] Error 1
Are invisible in throught __repr__ method:
StarshipHull(item_type=<ItemType.HULL: 4>, display_name='...', description='...', armor_mount_slots=2, secondary_weapon_mount_slots=2)
But are given Filed class:
(Pdb) self.armor_models
FieldInfo(default=PydanticUndefined, default_factory=<class 'list'>, extra={})
Consider looking into Attrs, quite possibly introducing to it validational part of pydantic with pydantic-core python binding.
So, I'll try another architectural approach (see below), since using attrs and pydantic in a same project is no way a real-world solution considering their similarity and my scope of a task.
StarshipLoadout shall be placed inside Starship Sprite class during initialisation, since ship for proper functionality requires equipment. Loadout itself shall hold any other delegated to specific sprite actions classes, storage, weapons, enegry etc. and since 80% of attributes are interconnected, whise changes impact everything else inside loadout, consider several scenarios of centralized mutable storage.
Either prop-drill loadout's self into every oriented subclass or consider talking to python-imported state instance object of single starship. Also, since business logic behind starship movement is stored insdide MVVM-oriented class Transmission, it may be the case of reusing same pattern here, whithout any redux/flux-like action constacts.
f985e19: required checks:
- given armor models
- gven secondary weapons