Hi Carlos, First off: thanks for the feedback, it is very useful to discuss various real world scenarios.
> On 28 Apr 2016, at 02:33, Carlos Lombardi <[email protected]> wrote: > > Hi, > > I want to use STON to enable the backup a graph of objects pertaining to an > application. Would it be possible to provide more details (maybe off list), I would like to have a better idea of the issue you are trying to solve. What does that mean 'not supported by STON', why is that so ? Why do you need to write extra information ? what is in it ? how do you deal with it afterwards ? > Some of the objects in this graph include, in their state, a Map that is not > supported by STON. > To write these objects, I would like to write via the standard procedure all > the instance variables unless that pointing to such a map, and then add a > modified version of that map by hand. > > To exclude the conflicting variable is easy, I just redefine > #stonAllInstVarNames at the class side as follows: > ^self instVarNames reject: [ :theName | (theName = #references) ] > in this way, I do not need to modify the method if the state of these objects > changes. Yes, that is one extension point. > On the other hand, I found not easy to use the standard mechanism for the > included instance variables. This mechanism is embedded in > STONWriter>>writeObject: . I found no option but repeat the logic codified > there, in the method #stonOn: of my class. > > The easiest way to let STON integrate the standard mechanism to store the > state of an object, with by-hand additions, is to slightly modify > STONWriter>>writeObject:, adding just one line. Objects including instance > variables would be written as follows: > > self writeObject: anObject streamMap: [ :dictionary | > instanceVariableNames do: [ :each | > (anObject instVarNamed: each) > ifNotNil: [ :value | > dictionary at: each asSymbol put: value > ] > ifNil: [ > anObject stonShouldWriteNilInstVars > ifTrue: [ dictionary at: each > asSymbol put: nil ] ] ] . > anObject stonAdditionalInfoOn: dictionary . ] > > the added line is the last one, the invocation to #stonAdditionalInfoOn:. Of > course, the method #stonAdditionalInfoOn: should be added to the Object class. > By redefining this method in my class, I was able to easily add the modified, > STON-compatlble value, to the values handled by the STON code. Overwriting #stonOn: is meant to be an extension point as well. > I did not need to modify the STON code to read the STON String to generate a > new object. How can that work ? Via additional accessors ? Like I said, a concrete example, maybe of the STON output would be helpful. > Do you think that doing this modification to STON could be a good idea? Customising STON is OK, it should indeed be possible without changing the core code. But I would like to better understand your use case before really commenting. Regards, Sven > Cordially - Carlos > > > PS: I envisaged as an alternative, to allow the following method in my class > > stonOn:stonWriter > stonWriter writeObjectAsMap: self > do: [:mapWriter | > // added code goes here > stonWriter writeInstVarsOf: self on: mapWriter > // added code goes here > ] > > To this end, the methods #writeObjectAsMap:do: and #writeInstVarsOf:on should > be added to STONWriter. The method > writeInstVar: aSymbol of: anObject on: mapWriter > could be offered as well, to allow more fine-grained redefinitions of stonOn: > , while keeping the ability to use the standard mechanism to store an > instance variable. > > I think that the option I described earlier is simpler, I include this one > because maybe other people would prefere it. > >
