nicwi@isy.liu.se ( Niclas Wiberg) (12/12/89)
For evaluation purpose i am trying to use the Eiffel standard library in a small size project. My opinion is that the documentation is poor. My problem right now concerns about the basic class STORABLE. As I dare not publish part of ICE copyrighted material, you will have to cope with my explanation. Objects of class STORABLE (or of a descendent class to STORABLE) has the features store and retrieve, which takes as argument a filename. Store works just fine, the problem arises when you whish to retrieve objects: 1. Before you can use retrieve, you have to Create an object of the desired class, which may involve a lot of work (as you cannot have several different Create routines). 2. Retrieve does *not* change the "Current" object, but (it is a function) returns a new object. My first attempt was to call retrieve from within Create (to overcome (1) above), but that did not work because of (2). An other approach would be to have an "dummy" object, to make the retrieval. But problem arises if you have class invariants. You don't want to create a big object structure, just to be able to retrieve old objects! Am I missing something? What is the recommended programming style? Thanks in advance. -- ---------------------------------------------------------------------- Niclas Wiberg nicwi@isy.liu.se Dept. of EE Linkoping University Sweden
bertrand@eiffel.UUCP (Bertrand Meyer) (12/12/89)
Article <1989Dec11.170552.8455@isy.liu.se> by nicwi@isy.liu.se (Niclas Wiberg) criticizes the interface to function ``retrieve'' used to retrieve persistent object structures (in the support library class STORABLE). The criticism is well-taken but the problem does not arise any more with the current version (2.2), where retrieval is done in two steps: call a retrieval procedure; then access the retrieved structure through attribute ``retrieved''. There is also a more flexible and general facility supporting persistence: the notion of environment. [It appears that the 2.2 shipment for Mr. Wiberg's institution is on its way. Please check with your distributor.] -- -- Bertrand Meyer bertrand@eiffel.com
keithc@cognos.UUCP (Keith Campbell) (12/16/89)
In article <1989Dec11.170552.8455@isy.liu.se> nicwi@isy.liu.se (Niclas Wiberg) writes: >An other approach would be to have an "dummy" object, >to make the retrieval. But problem arises if you have >class invariants. You don't want to create a big object >structure, just to be able to retrieve old objects! Dr. Meyer posted an article some time ago which suggested that he was considering the addition of a feature which would allow the Storable class to be more useful. That feature would allow the invocation of features on a void instance. Retrieve could then be changed so operate in this way avoiding the necessity of creating your large object. For the mean-time, I would suggest that you simply write a dummy class like the one below. CLASS Retriever[ T -> Storable ] -- The constraint isn't really necessary. EXPORT retrieve FEATURE retrieve( fileName : String ) : T IS -- This is essentially a copy of Storable.retrieve -- except that c_retrieve returns an object of type "T" -- instead of "LIKE CURRENT". EXTERNAL c_retrieve : T LANGUAGE "C"; DO Result := c_retrieve( fileName.to_c ); END; -- retrieve END -- CLASS Retriever[ T -> Storable ] You can inherit or create a local Retriever[ BigObject ] and use it to retrieve the structure created by BigObject.store. -- Keith Campbell Cognos Incorporated S-mail: P.O. Box 9707 Voice: (613) 738-1338 x5222 3755 Riverside Drive FAX: (613) 738-0002 Ottawa, Ontario UUCP: uunet!mitel!sce!cognos!keithc CANADA K1G 3Z4