Rowan should preserve foreign class properties (like the Pharo package: field), since that can be a major barrier for sharing packages between Pharo and GemStone

[dalehenrich]

While working on #829, I was reminded of the fact that Pharo writes out a package: field with the name of the class' package. Pharo doesn't appear to care whether or not the field is present on read and happily adds it back in on write.

The intent behind the tonel spec is that foreign class fields be preserved across read/write cycles ... so this issue should be addressed as part of #829 work

[dalehenrich]

Preserving the foreign properties is just one of the issues that (ultimately) needs to be addressed, we also need to preserve the order of the foreign properties relative to the other standard properties ... since the goal is to avoid arbitrary changes to the class definitions when sharing code between Pharo and GemStone (and other platforms) there needs to be an agreement between all parties involved on the ordering of all properties (foreign or not) ...

For now, the implementation GemStone will handle the foreign Pharo packageName property, however there are a number of GemStone-specific properties that could be applied to shared classes, and the Pharo implementation would need to be changed to preserve the GemStone properties that could legitimately apply to shared classes.

At a minimum, I will create a RowanSample9V4 spec that contains a full set of GemStone class properties and the Pharo packageName property.... I will include an example of GemStone traits definition, for completeness ...