I should have thought of this earlier: Dolphin's #environment concept will do the job. Instead of hard references to classes or adding a new name space syntax, one can simply use messages to delay binding. I should *look* at Fuel to find an example, but suppose there is a class FuelDWORD. Instead of referencing it, one would do something like
Fuel formatDWORD or Fuel environment formatDWORD or ( Fuel version:3 ) formatDWORD etc. There are many ways one could handle the details, but #environment or #version: can return a "system dictionary" (an ordinary class would suffice) that is version specific, allowing FuelDWORD_3 to be used by code that otherwise knows only that it should use given selector to get the class it needs. To develop the different version/environments, one could use the RB to rename classes and then save the new version classes in a Fuel sub-package. Add FuelVersion3 to give out the correct selectors, and a basic facade should be able to make everything go with the various versions in the system at one time. Finally, one could facade the entire serializer, something like (Fuel version:3) save:anObject on:aStream. (Fuel version:3) readFrom:aStream. etc. Does that make sense? Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Martin Dias [[email protected]] Sent: Saturday, October 15, 2011 9:06 AM To: [email protected] Subject: Re: [Pharo-project] When will Fuel file format stabilize? I like the ideas of Stef and Ben of loading multiple fuel versions at the same time. Do you know something done in that sense? Martín On Sat, Oct 15, 2011 at 7:09 AM, Mariano Martinez Peck <[email protected]<mailto:[email protected]>> wrote: On Sat, Oct 15, 2011 at 11:49 AM, Philippe Marschall <[email protected]<mailto:[email protected]>> wrote: On 11.10.2011 21:51, Mariano Martinez Peck wrote: > > > On Tue, Oct 11, 2011 at 8:55 AM, Philippe Marschall > <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>>> > wrote: > > On 10/08/2011 10:42 PM, Mariano Martinez Peck wrote: > > s > > > >>> > >>> This is IMHO more than necessary for Fuel to become a production > ready > >>> serializer and I'd say Fuel is now "old enough" to become such :) > >> > >> Yes. > >> Now what I would love is that even if fuel changes that the > evolution of > >> information > >> is taken into account because like that it will be exercised for > real. > >> > >> > > No, that's impossible, and if posible, it is not worth it. > Migrating from an > > old format to a new one is extremelly complicated and innecessary. The > > easiest way to solve this is to take the correct version of Fuel, > > materialize the graph from the stream, load new version of Fuel, and > > seriaize it again. That the easiest, more secure, and more practical > > approach I can see. > > That is horribly naïve an excludes fuel from a lot of use cases. You > can't use fuel for "archiving" objects outside of the image because you > will never know whether you will be able to read them in again because > the format changes. You will always need to have "live" ones in the > image. > > > No. That's incorrect. You won't be able to do that ONLY if you update > Fuel to a new image that breaks format. > You can still continue to use the same version and you will never have > that problem. So, again, why you need to update Fuel? Because it's old software. Bugs may not get fixed. It may not work in newer Pharo versions. I may have dependencies on other libraries that may require a new version of Fuel. You name it. I understand. What I mean is that depending on the changes and the amount of work, you can just adapt Fuel to new versions of Pharo but without changing its format. I mean....say you were in Fuel 1.4. You don't need to move to Fuel 1.8 just because. You can just try to fix 1.4 to make it work in latest pharo. That's EXACTLY what we do with ReferenceStream and friends. The only difference is that the Pharo team does that because it is in the core. But yes, it may happen that ideed you will require a new version of Fuel. > Why SmartRefStream does not have this problem? because it hasn't > changed in the last 10 years. > So..do the same, take an specific Fuel version and keep it for 10 years. > Just update it to make it work in Pharo without changing the format and > you are done. > > > > That means you can't use fuel for anything Monticello related because > you may never be able to load those versions in again because the file > format has changed in the mean time. > > > I guess that in the end, if someone can really do something for > Monticello on top of Fuel it will be like 2 years from now, and at some > point Fuel format will be stable. > And as Stef says...you always have the code there in case of problems. Monticello is just an example for a case where I want to store objects outside of the image. Well, then you can just wait until we finish. Give us one year more. Instead of doing 1-year-long releases, we like to do 3 months releases. But again, that doesn't mean you have to update... Cheers Philippe -- Mariano http://marianopeck.wordpress.com
