bertrand@eiffel.UUCP (Bertrand Meyer) (03/11/89)
From <112@eiffel.UUCP>, reposted by me but originally from Jean-Michel Cornily (CNET, Lannion, France, uunet!mcvax!cnetlu!cornily): > A second problem resides in our need to share objects between two Eiffel > process via UNIX sockets. Champ-de-Mars tells that, in release 2.2, the > routine Out will permit to flatten an object, i.e. to transform it into > a string. So, we can send it to the second process via a socket. > How can we recuperate an object at the other side (i.e. to "unflatten" > it) ? Out does not appear to be the proper technique here since there is no need to go through a text representation. Furthermore there is no need to wait for version 2.2, as explained below. Before suggesting a solution let us first note that the problem is conceptually less trivial than it seems. Transmitting an object is fine but what if this object contains references to other objects? Most likely, you won't want to replace these by void references, losing the semantics of the object. Instead, you will need to transmit the object and all those to which it is related directly or indirectly. But to prepare an externally accessible version of an object and all its direct or indirect neighbors, you can use an existing facility from the Basic Library: ``store'', from class STORABLE. If, in any class that inherits from STORABLE, you write x.store ("file name") the result will be to produce in ``file name'' an external representation of the entire structure of objects starting at x. As mentioned in the library manual, page 75, this includes not just the object referred to by x; any object referred to directly or indirectly by x will be copied. Cyclic structures are no problem. On the other end, you may retrieve the object in the same or another session by x.retrieve ("file name') where x is a reference to an object of the same type (note that this object must have been created, otherwise retrieve won't work). So primitives store and retrieve seem to provide the required functionality. They apply to files rather than sockets, but it won't be very difficult to write a small utility that transmits the file over the socket. In the next release we will provide this as an option in class STORABLE (with pipes being another possibility). -- Bertrand Meyer and Jean-Marc Nerson, Interactive Software Engineering. bertrand@eiffel.com, marc@eiffel.com