comp.lang.ada
 help / color / mirror / Atom feed
From: Paul Johnson <Paul@treetop.demon.co.uk>
Subject: Re: use eiffel to build a CAM library?
Date: 1998/01/22
Date: 1998-01-22T00:00:00+00:00	[thread overview]
Message-ID: <J5wZVOAl1ox0Iwbw@treetop.demon.co.uk> (raw)
In-Reply-To: shanemEn5Ju8.2z6@netcom.com


In article <shanemEn5Ju8.2z6@netcom.com>, Shane Miller
<shanem@netcom.com> 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    |




  parent reply	other threads:[~1998-01-22  0:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-01-21  0:00 use eiffel to build a CAM library? Shane Miller
1998-01-22  0:00 ` Thomas Beale
1998-01-22  0:00 ` Paul Johnson [this message]
1998-01-24  0:00   ` Thomas G. McWilliams
1998-01-25  0:00     ` Rob Heyes
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox