From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,30cdfbb433fa5e47 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,30cdfbb433fa5e47 X-Google-Attributes: gid103376,public From: Paul Johnson Subject: Re: use eiffel to build a CAM library? Date: 1998/01/22 Message-ID: X-Deja-AN: 318411728 Distribution: world X-NNTP-Posting-Host: treetop.demon.co.uk [158.152.55.135] References: Organization: home MIME-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1998-01-22T00:00:00+00:00 List-Id: In article , Shane Miller writes >the bug was put in my ear about eiffel. i am curious to >hear from people who have used eiffel to develop a library >(and, even, better those who have done libraries in C++ too) I've written libraries in C++, and done a data structure library in Eiffel for my own interest. >* what did you do for GUI? if you did not want to use eiffels >WEL/MEL libs but wanted to use another lib (such as Roguewave's >ZIP/ZAPP) how did you get eiffel's runtime system to work with >an external package's event-loop? I've used WEL. Basically, its not a run-time issue at present. When we have concurrent Eiffel compilers (real soon now :-) then you will need a non-blocking approach to GUI events. For now, just call the get_next_event routine or whatever, or just go into the event loop routine that does this. Its a pity that the run-time cannot use the time spent waiting for an event to do a quick bit of GC. Eiffel has good C and C++ linkage, but wrapping a 3rd-party library in Eiffel classes is tedious. Object Tools (used to be called Sig) do a neat GUI-builder called Display Machine. Take a look at it. >* what about database support, in particular, informix, oracle, >and sysbase? ISE produce an add-on with ODBC connectivity. You just dump your objects into it. I don't know about performance, but I suspect you would be better off with an object database instead. Relational DBs were designed for table-wide batch operations, not individual row gets and puts. I've never used these. Or you can write an interface to embed SQL in Eiffel yourself. Eiffel has excellent interfaces to C and C++. >* is this short form nonsense? who actually comitted to giving >the user or client programmer nothin' but what you generated >in short form? ISE says it can output that to HTML, ps, ect. >eg. what other things did you do to provide documentation? Short-flat-form is one of the key arguments for Eiffel. It acts as the reference manual for the library. Of course you still need natural- language documents to introduce the library, show examples of use and so on. But they are much less sensitive to changes in the code than the reference documents. >* are BON diagrams useful for teaching and/or communicating or >documenting the library so that others may use it? Never used BON, so I can't comment. Like all graphical notations, I suspect it requires the others to be conversant with the notation. You may be better off with one of the Eiffel-UML tools instead. >* with respect to memory management and object sharing/ownership, >how does eiffel impact the following two (similar) scenarios: >(a) you have a object containing 50 values. the user asks to >display values in a form. you use a "table" or "spreadsheet" >like UI object to edit those fifty values. say 10 are modified. >Q: what do you do if the user clicks on cancel? those 10 values >cannot be commited. how does eiffel deal with copy semantics? >reference vrs deep-copy? Depends on the GUI. Eiffel has both shallow-copy and deep-copy built in. Also compound objects such as arrays and lists generally redefine the shallow copy routine to do the "right thing" in their case. So in this case I would say you edit a shallow copy of the object, and then copy it back onto your original when "OK" is clicked. >(b) your library maintains a list of objects. each object is >real big. Q: what do you do if a client programmer who's using your >lib wants to inspect the list? on the library side, you cannot >allow the client programmer to modify the list or the state of >any object in the list. how can you share the list without doing >a deep copy? Define "read-only" ancestors to your classes, and export those using polymorphism. That way the type system prevents the programmer using the modification routines, but they are available internally. See my paper on "Re-use through fine grain inheritance" in S-P&E Dec 92 for more details. > ok, now the client programmer *needs* a copy of the >list because he needs it for a computation but also wants to >change the state of the objects in the list. what's the least >painful way of giving a copy to the client from the libraries >perspective? Give him a copy of the list. Either deep or shallow, depending on what you want. Actually, these questions rather suggest a poor OO design. A good OO design should preserve the "object identity principle", which states that for anything out there in the "real world" that you are modelling, there should be exactly one corresponding object in your system. >(hint in C++ you use const functions and reference-counting with >copy-on-write. how, really, does garabge collection make this >easier? It means that if you only want to pass a reference to the list (in accordance with the object identity principle) you don't have to keep track of who is using the reference in order to determine when you can deallocate the memory used for the list, or any other object. Also, the data required for GC is also used to do deep copy operations. >* is there such an aminal as callbacks in eiffel? OO designs don't use callbacks in the C way: you should use inheritance and polymorphism instead. These play similar tricks with function pointers behind the scenes, but you don't need to worry about that. > suppose >i have a complex business system containing 200 objects how do >i handle each of the following scenarios: See the Gang of Four "observer" pattern. >any thoughts or ideas or experience is greatly appreciated. >i have ordered two of myers' books and hope it discusses these >very tricky questions of object ownership and copy-semantics. Object ownership is simply not an issue in Eiffel systems. GC does this for you. Paul. --------------------------------+--------------------------------- Paul Johnson | You are lost in a maze of twisty Email: Paul@treetop.demon.co.uk | little standards, all different. paul.johnson@gecm.com |