Hello, thank you all for your tips! I'm away from my PC for a month so I 
will experiment with your proposals when I come back.

@Ulises, @Betrand: Hiding the access behind functions to limit the change 
to them is something I have also though of. The disadvantage is that I 
loose the benefit of destucturing and more documentary function signatures. 
But I want to try this out to see how it turns out to be,

@Aramndo: Thank you, that is a neat idea to use a temporary transformation 
fn that can produce the old structure from the new so that I could 
propagate the change slowly, one step at a time. I will look more into 
that. And if I am lucky with time, I will share my experience via a blog 
post.

@Laurent: I want a save way to change the data structure - this temporary 
ability to work with both shapes of data is one possible way of achieving 
it. Otherwise you captured it quite well. "You could implement a 
transitional protocol which would behave differently depending on how data 
is accessed" - yes, that is what I have been thinking about. I have never 
done such a thing but I guess it should not be too difficult. You have a 
good point with the necessity of compromises. I guess I can draw 
inspiration from Om's cursors<https://github.com/swannodette/om/wiki/Cursors> 
that 
behave as data but are more than that, knowing their place in the larger 
structure and producing new cursors when accessed - they too have limits 
such as not working with lazy seqs (so f.ex. (remove ..) must be wrapped in 
(vec ...)) or sets.

I hope I will eventually get back with a report how the different 
approaches worked. More ideas are still welcome :-)

On Saturday, May 24, 2014 10:19:31 AM UTC+2, Laurent PETIT wrote:
>
> So you want a transition phase where existing consuming code can work with 
> both data shapes, and then start fixing functions one at a time to use the 
> new data shape, until you reach the point where you have only the new data 
> shape produced / consumed in your application?
>
>
> Current consumer functions expect the data to behave as a vector: calling 
> seq on it should produce an deterministically ordered list of property 
> values, calling nth should work, etc.
>
> Upgraded consumer functions will expect the data to behave as a map, so be 
> able to pick keyword keys.
>
> You could implement a transitional protocol which would behave differently 
> depending on how data is accessed (then delegating to the underlying 
> fields).
>
> You would probably have to make some compromises during this transition 
> phase. E.G. refactored consumer functions would not be able to call (seq) 
> on the map (or they would get the data vector back).
>
> HTH,
>
> -- Laurent
>
>
>
> 2014-05-22 10:17 GMT+02:00 Jakub Holy <jakub...@iterate.no <javascript:>>:
>
>> I have a nested data structure, used by a bunch of functions that presume 
>> knowledge of its structure, and I wonder how to change a part of the 
>> structure in a safe way, preferably in small incremental steps, rather than 
>> having my code broken until I update all the functions and tests for the 
>> new structure. I believe many of you must have experiences with this, would 
>> you care to share some tips?
>>
>> The data structure is first built incrementally and the collected data is 
>> later summarized. Instead of replacing the raw data with their summary, I 
>> want to keep both, so I want to wrap the data with a map; i.e. from:
>>     { <id> [ data...] }   ;; later replaced with {<id> summary}
>> to
>>     {<id> {:data [data...], :summary ...}
>>
>> I have a number of functions operating on the structure and tests for 
>> those functions (with test data that also need to be updated w.r.t. the 
>> refactoring).
>>
>> When I change one of the functions to produce the new data structure 
>> (i.e. data wrapped in a map instead of the data itself), everything else 
>> breaks. So I fix some tests and another function and get even more 
>> failures. This does not feel as a good way to do it as I prefer to have 
>> limited 
>> red <http://www.infoq.com/presentations/The-Limited-Red-Society> and am 
>> fond of parallel 
>> change<http://theholyjava.wordpress.com/wiki/development/parallel-design-parallel-change/>for
>>  that reason.
>>
>> Ideally, I would have an automated refactoring or the possibility to wrap 
>> the data in some kind of a two-faced proxy that could behave both as a 
>> vector (towards the old code) or as a map containing the vector (towards 
>> the updated code) [some thing like lenses/cursor?!]. I haven't either so I 
>> guess the only option remaining is a well-controlled process of updating 
>> the structure and code. Any advice?
>>
>> Thank you! /Jakub
>> -- 
>> *Forget software. Strive to make an impact, deliver a valuable change.*
>>
>> *(**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig 
>> og muntlig. Takk!**)*
>>
>> Jakub Holy
>> Solutions Engineer | +47 966 23 666
>> Iterate AS | www.iterate.no
>> The Lean Software Development Consultancy
>> - http://theholyjava.wordpress.com/ -
>>  
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to