Using Read From Binary File as an object factory

[Mads]

Part question, part idea:

If we write a child object to a file using write binary, we can read it by specifying the parent as the data type; and the output will in fact contain all the information of the child. We do not need to read the file again to instatiate the original child, we just need to run "To More Specific Class" on it to get the child.So, the binary read has some in-built magic that allows it to figure out that it needs to read all the data within the child, even though the child is not specified at read time. So why could it not instatiate the child then and there? - If the output of the read already had the original class there would be no need for a factory pattern that uses a case structure to specify which child class it should be specified as. The read would act as the factory on its own (assuming the child class is in fact already in memory...). So the question is; why is it not like that already?  Is there a show stopper for such an idea, and if not - why has it not been made that way already (in other words; why would it be a bad idea)?

As it is now, if I want the file to specify enough for me to instatiate the correct child, I have to add a child type information field in the parent, extract that from the output of the binary read, then feed that to a case structure that feed the correct child class into the to more specific function - and only then do I have the actual object that was stored in the file...

[antsundq]

Hi,

It is an interesting idea, but as I see it there might be a few problems with implementing this. 

If I have understood it correctly, you propose that when a binary file is read as a parent data type it should be automatically cast as a child. I can think of a few cases where this might be a problem. For example you might want to read multiple objects of different classes, all being children of the same parent, and these children have child specific properties or methods that override parent properites or method. If in this case the children are automatically cast to the more specific class on read it would be hard to predict what the program would do. 

/Anton

[Mads]

>If I have understood it correctly, you propose that when a binary file is read as a parent data type it should be automatically cast as a child.

If it was a child when it was saved, then it should come ouf as a child when read yes. The read function already reads all the data (even if the child has additional private data), but you have to figure out that it was a child by other means, and do the to more specific conversion yourself. It is far more likely that you want the more specific class, that is why you saved the data as that class in the first place...So it is predictable what will happen; if you saved a child, you will now get a child back - and the dynamic functions will adapt accordingly.

If that is a problem you can always run a to more generic on it, which is easier as you will then know what class that is (the parent). The implicit information loss we have today (that we need to know/figure out whether it was a child and if so which) is the problem I would like to attack by making the read binary just a tad "smarter".

[antsundq]

>If it was a child when it was saved, then it should come ouf as a child when read yes.

But, according to the first post, you specify the parent as data type when you read it? In this case you will have to use the to more specific to get access the properties of the child. If the child would be output as default this would be counterintuitive since the data is read as a member of the parent class. So what you need would be a to more specific function that figures out the class of the child without having to specify it? 

/Anton

[Mads]

Yes, as we do not know which of the classes there is in the file up front, the only way to read it would be to specify the parent.

However, the read function already handles this nicely; it will read all the data even though it was in fact a child that was saved. The problem is that it will not produce the child. I believe it has the information required to do so, and that would make it possible to save a set of related classes directly to file, and read them back . without losing information  about their relationships (read: having to add additional code to keep that information).

You could say that this would be similar to having the read function always know the type of the data it reads, with no need for a data type input. Today we can choose to have the write function add length information as a header in the file automatically, but not the type. If we could choose to add type as well, the read function could produce a type at run-time with no type information at all, but that poses additional challenges.

Here, in this idea/question, a parent class is indeed specified and the read function is already able to read children properly. It just does not allow you to fully utilize that.

[M_Peeker]

I haven't worked with this functionality, but for the object to be loaded to the right class without pointing it out somehow, the file would need to contain the entire class. Or at least, be able to tell where to load it from, something that could very well be different on different systems using the class.

[Mads]

"I haven't worked with this functionality, but for the object to be loaded to the right class without pointing it out somehow, the file would need to contain the entire class. Or at least, be able to tell where to load it from, something that could very well be different on different systems using the class."

Yes, that is one of the weaker parts of the idea, and is why I posted it partly as a question. - The file itself contains all the data (that's why we can use the to more specific function on it afterwards), but I am not relying on having the class definition itself here, that would become a mess.  We do (with this idea) specify the parent though, so there is a reference there to the class, and consequently to the relationships within it...But it does mean that the child classes must be in memory (if they already are when the parent is used/loaded then that solves it...), and behind the scenes the functionality will have to look for the child that matches what it finds in the file.