Mariano Martinez Peck wrote:
**
Mariano Martinez Peck wrote:
Another thing would be to somehow document the requirements for loading
the file. For example, in the case of FuelMooseExtension, it is required
that Fame and potentially FAMIX are loaded.
Yes.
Do we get any support from Fuel in this regard?
Not really. If you have serialized something in an image XXX and you have
serialized instances of that image, and you try to import in an image YYY
where you DON'T have those classes, then you will have a clear error saying
"FAMIXXXX not found in Smalltalk globals".
What happens in this instance? Is the load atomic or does it end up
half loaded?
It is atomic. However, think it another way. Imagine that when you do
FLMaterialize materializeFrom: aStrema I have to give you back the object
graph. If an error happens in the middle, the "part" of the graph being
materialized is just some variables in some code of the materializer. Is
not "registered" somewhere in the system. So even if there could be some
part of the graph, the instance of the materializer will be at some point
garbage collected, together with the rest of the stuff.
So..to make it clear, it does not exist what you say as "half loaded". I
give you back the graph or I don't.
Is there a way to list all required classes before performing an actual
load ?
Not right now, but we could add it if desired. We already talked about
Martin about that. The idea was to kind of "simulate" the materialization
(reading the stream) and get an object with information. So that you can
ask for example, the needed classes.
Now Martin pointed me out the previous discussion we had about it.
Basically, it consist of something like this:
info := FLMaterializer newDefault infoFrom: stream.
info globalClasses --> {Point. Zaraza. Etc.}
info internalClasses ---> {}
info objectCount ---> 32000
info clusterCount ---> 5
info fuelVersion -> 15
info allGlobals -> {Transcript. ... ]
etc...
what do you think?
Looks good. Whereas I assume that globalClasses lists every class
withing the fuel file, I would perhaps also have a line:
info requiredClasses --> { ClassNotInCurrentImage }
as a short list of classes that need to be loaded.
-------------
Now another passing thought - to what degree is compatibility required
to match between in-image Class and serialized class in-file. For
example, you export objectA of type classA when classA defines an
instance variable "X", but subsequently "X" is removed and then you try
to import objectA back in ?