pffff thank you. The word 'awesome' is too much, but well, I can put the snippet somewhere in the doc.
I don't know if this should be the default behaviour in Fuel, since it will add the dependency to Ring. Also we can discuss about removing the "defensive" error during serialization: as you could see, technically there is no problem to serialize the obsolete class. We decided to raise an error just because as users we found that almost always when you are serializing the obsolete, it was due to some mistake, and you discover that the obsolete was in the .fuel file later when you materialize. Alternatively, we could just raise a "class not found" error during materialization. cheers, Martin ps: I'd like to see the video of Max's presentation in PharoConf! On Sun, Apr 7, 2013 at 2:47 PM, roberto.mine...@usi.ch < roberto.mine...@usi.ch> wrote: > I'd say that handling obsolete reference this way is very good! I'd put > this behavior in Fuel! > > Cheers, > R > > On Apr 6, 2013, at 2:27 PM, Mariano Martinez Peck <marianop...@gmail.com> > wrote: > > > Martin, should be manage obsolete always that way (meaning to put such > behavior directly inside Fuel)? > > If not, could be write your awesome code in the Fuel website? > > > > Thanks!!! :) > > > > > > > > > > On Sat, Apr 6, 2013 at 8:26 AM, roberto.mine...@usi.ch < > roberto.mine...@usi.ch> wrote: > > Martin, your solution is awesome. > > > > I've seen the presentation at Pharoconf about setting an analyzer to the > serializer and I was thinking in that direction. > > > > Thanks a lot, > > R > > > > On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchod...@gmail.com> wrote: > > > > > As Fernando said, probably is better for you to substitute the > obsolete class by a ring definition. Look here: > > > > > > http://ws.stfx.eu/OAVG8IXKWOYA > > > > > > Don't need to filein the workaround of my previous email. > > > > > > Martin > > > > > > > > > On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchod...@gmail.com> > wrote: > > > Hi, > > > I'm sorry for my delay. I didn't stop to think a good solution. There > were interesting answers before mine. But if it's a prototype... maybe this > workaround helps you. I played with this code: > > > > > > http://ws.stfx.eu/HYWM1ZB9R45K > > > > > > (the first time I use the shared workspace :-) > > > > > > if you file in the attached file, it materializes the new A class. > > > > > > But this will be not useful for you, if either: > > > - you don't have the "original class" at materialization time > > > - you don't want to know if the class was obsolete at serialization > time > > > > > > HTH > > > Martin > > > > > > > > > > > > On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <ya...@rogers.com> wrote: > > > On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.orgwrote: > > > > > > Is there any way to "browse" through such references to understand > where are they? > > > > > > From an inspector, choose the "Explore pointers", making sure you've > selected the object that you're trying to understand what is referencing it. > > > > > > It takes trial & error, and intuition on which pointers to follow. > This method has often been unsuccessful for me. > > > > > > Another approach (my memory is fuzzy), was to put a halt at a suitable > place during the Fuel serialization. Then explore the intermediate > structures used by Fuel, to try to find out why Fuel thinks it needs to > serialize that object. > > > > > > Yet another approach is to put a halt in the Fuel materialization, and > explore the intermediate structures used by Fuel. You might even set up a > mapping of the obsolete class to some temporary class, which allows Fuel to > fully materialize the saved objects. You can then explore the Fuel > intermediate structures, as well as the final de-serialized object > structure. > > > > > > > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > >
