STON incorrectly converts instances of Text

[dalehenrich]

Text is a subclass of ArrayedColllection and STON uses encodeList: to encode the Text, but Text doesn't really take advantage of is array-ness, the real action for Text is in it's string and and runs instance variables .... the implication here is that even variable subclasses can have instance variables in addition to the indexable portion...

[dalehenrich]

As a workaround I have pulled the stonOn: and fromSton: methods down from Object into Text, but this is a point solution ... a better solution involves a combination of a list/iv syntax ... without thinking to hard, it isn't clear to me that both named and indexable elements can be easily combined ...

[svenvc]

Hi Dale,

On 21 Nov 2012, at 02:52, Dale Henrichs notifications@github.com wrote:

Text is a subclass of ArrayedColllection and STON uses encodeList: to encode the Text, but Text doesn't really take advantage of is array-ness, the real action for Text is in it's string and and runs instance variables .... the implication here is that even variable subclasses can have instance variables in addition to the indexable portion...

Thanks for the feedback. This is an interesting case indeed, I didn't know there were such classes.

Now, STON has limited ambition: it does not aim to be able to serialize everything, like Fuel does.

The automatic encoding, as implemented by Object>>#stonOn: clearly states that it will do something acceptable for normal objects, which will probably cover most simple application / domain level objects, but does not try to do anything with variable instances (let alone the combination of the two which I didn't know about). But is even for normal objects, the useful case of transient or lazy instance variables is not covered as such.

A possible solution is to write a custom #stonOn: fromSton: pair for Text.

Do you think there are many more such classes ?

Sven

[dalehenrich]

Sven,

I assume that cases like Text are relatively rare, but they do show up occasionally ... We have several cases in GemStone of indexable classes with instance variables one notable case is UnorderedCollection ... a common superclass for Bag and Set ... but the instance variables are part of implementation details that probably shouldn't be exposed in something like STON ...

For my usage of STON, I am not expecting everything to get serialized either ... I am passing a limited set of Smalltalk objects back and forth between Pharo and GemStone and just yesterday I decided to ship Text objects and ran into this issue ... I added the #stonOn: #fromSton: pair of messages and got going again, so custom fixes are fine with me ...

I am a little curious what the output would look like if I had both named and variable fields that I needed to represent. I assume that STON has made a basic assumption that it will be encountering either named fields OR indexed fields, so I'm not sure how easy it would be to represent an instance with both ...

If there is a solution then presumably it could be added to code to handle the case when the class #isVariable and named instance variables are present ... using the standard encodeList function otherwise ...

So I think the question is: can named and indexed fields be easily represented in STON?

Dale

[svenvc]

I am afraid that there is no general solution:

• collections (indexed instances) are naturally mapped to a list (except for keyed collections)
• regular objects with named instance variables are naturally mapped to a map I can't immediately see how these two could be easily/elegantly combined.

In the Text case, the indexed portion is actually not used, the subclassing is not for structure but for behavior. It feels very natural to make STON encoding specific for that class.

I can imagine that in GemStone there are more special collection classes, but like you say, some of there in memory structure does not have to be serialized in STON.

[svenvc]

https://github.com/svenvc/ston/commit/8815dff81b7d4110d095f0e7cb20acae5d4a4ada