Re: Complexity of new hardware

> From: Alen Ladavac [mailto:[email protected]]
> 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


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list