5389 made ActiveMove a class, which brought some concerns:
Hm I don't think I like the idea of ActiveMove being its own class. Especially since it doesn't actually extend Move, it actually makes move properties non-readonly.
However, I'm not sure the previous approach (before it was made it a class) was any better, as we'd often simply cast arbitrary objects to /** @type {ActiveMove} */, and simply cloning + adding crap to a Data.Move is not ideal for performance, as thanks to the monomorphism optimizations we would ideally be assigning everything on creation in the literal/constructor. From a serialization point of view, detecting an ActiveMove without the constructor becomes more difficult (looking for a hit field or similar is somewhat error prone, so I'd probably end up not being able to collapse the attributes cloned from Move).
Serialization concerns would have us create an object that looks like:
Performance concerns would lead us to not modifying fields of the existing Move object, which the ActiveMove-as-a-class and the strawman interface above would support.
From conversations with @Zarel it seems like he'd prefer the simplicity of reverting back to the old ActiveMove format and simply added a getHitData to Pokemon.
To be clear, I think 'simplicity' and 'readability' trump 'serialization/performance concerns', but even with the old approach we played fast and loose with casts and I don't think the ActiveMove concept was optimal.
5389 made
ActiveMove
a class, which brought some concerns:_Originally posted by @Zarel in https://github.com/Zarel/Pokemon-Showdown/pull/5389#discussion_r271868604_
and importantly also caused some crashes. It also presents some challenges for serialization in #5270, as I need to include a
_class_
tag:However, I'm not sure the previous approach (before it was made it a
class
) was any better, as we'd often simply cast arbitrary objects to/** @type {ActiveMove} */
, and simply cloning + adding crap to aData.Move
is not ideal for performance, as thanks to the monomorphism optimizations we would ideally be assigning everything on creation in the literal/constructor
. From a serialization point of view, detecting anActiveMove
without the constructor becomes more difficult (looking for ahit
field or similar is somewhat error prone, so I'd probably end up not being able to collapse the attributes cloned fromMove
).Move
object, which theActiveMove
-as-a-class
and the strawman interface above would support.ActiveMove
format and simply added agetHitData
toPokemon
.To be clear, I think 'simplicity' and 'readability' trump 'serialization/performance concerns', but even with the old approach we played fast and loose with casts and I don't think the
ActiveMove
concept was optimal.