use eiffel to build a CAM library?

[shanem@netcom.com (Shane Miller)]

hi:

i was considering using C++ to develop a library for use
within electronic manufacturing.  in short, we wanted the
library to do for CAM systems what other C++ libraries
have done for database systems: one API works on informix,
sysbase, oracle.

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)
to comment on the following.  but also ADA-95 people.  i
think i made a mistake but not examining ADA-95 and eiffel
and their respective tools and third-party libs as solutions.
i only looked at C++:

* 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?

* what about database support, in particular, informix, oracle,
and sysbase?

(note: a library does not count unless you used with your 
language be it ADA-95 or eiffel.  i am trying to make a 
decision based upon experience not on-paper options. C++
has database and GUI libs down 7 ways from sunday.)

* 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?

* are BON diagrams useful for teaching and/or communicating or
documenting the library so that others may use it?

* 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?

(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?  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?

(hint in C++ you use const functions and reference-counting with
copy-on-write.  how, really, does garabge collection make this
easier?  i don't eiffel makes this any easier than any other 
language "makes it harder" relative to eiffel.  i am really
curious on this point).

* is there such an aminal as callbacks in eiffel?  suppose
i have a complex business system containing 200 objects how do
i handle each of the following scenarios: (a) object A wants
to change the state of object B.  but object B knows that it
first must ask permission from objects C and D.  the only 
reason B knows this is because, dynamically during runtime,
C and D found out about B and registered themselves with B
saying "look, if anybody tries to change you, consult me 
first: i may allow or disallow it".  so again, A tries to
change the state of B; B contacts C and D and says "ok here
is the proposed change, is it ok?".  if both C and D say
yes then B proceeds with A requests else nothing happens.

(b) simlarly, C and D may register themselves with B and
say "only notify me if your state changes; tell me what
changed but i don't care to stop the change".

(hint: in C++ you use function ptrs or functors, and either
pointers or references for the objects A,B,C,D)

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.
lazy-evaluation and copy-on-write are neat ways to similuate
copy-semantics with only reference-sematics until the user
really tries to change the object.

in the above example, if the list of big objects contains
100 entries and the user (after he obtains his "copy")
only modifies 35 objects, then copy-on-write saved 65% 
of the maximum amount of work (eg. if you deep-copied every
one of the 100 objects that would 100% work).  these issues
are consisently *NOT* talked about in eiffel literature.

shane miller
geferan systems

-- 
--------------------------------------------------------------------
shanem@netcom.com | Remember: know where you're going and then who's 
804.673.4966      | going with you.  Never get the order mixed up.
--------------------------------------------------------------------
Beware of the software trap: because I can do x, I should be doing x
--------------------------------------------------------------------