Re: [Algorithms] Complexity of new hardware

[Adrian S. <st...@8m...>]

> From: Alen Ladavac [mailto:ale...@cr...]
> Similar stuff here. UI-specific info, network-specific info, hints on
> how to behave on clipboard operations, per-class non-member info, any
> additional custom info etc.

Would you mind sharing a field definition that contains that level of
annotation?  You can see how cluttered our definitions get in my article,
but I'm having a hard time envisioning it in your syntax.

> Isn't that unnecessary? With proper format version tracking, you can
> delete and add members to a class without keeping the old members as
> clutter (in 99% most cases).

The situation I'm trying to describe is this: someone writes a class that
holds an angle in degrees.  Later they decide it would be more prudent to
store the value in radians.  They aren't just removing a field, they're
converting it.  In our system the original reflection definition would look
like this:

.field("angle", &MyClass:m_angle)
[
	Prop::SaveLoad()
]

And the new definition would look like this:

.field("angle", &MyClass::GetAngleDegrees, &MyClass::SetAngleDegrees)
[
	Prop::Load()
]
.field("angleRadians", &MyClass::m_angle)
[
	Prop::SaveLoad()
]

Other than the unfortunate code bloat of adding the getters and setter for
degrees, the reflection definition automatically converts old data and loads
new data with zero cost.  It also preserves compatibility with scripts.
When we can afford to stall production and batch process all the data for
all the projects we have going, we can remove the "angle" reflection field
from the code.

Adrian