READ 1ST: use eiffel for CAM library development?

READ 1ST: use eiffel for CAM library development?

[Shane Miller]

sorry -- the other version i wrote was rushed and
a little unclear.  i rewrote it here and make it
more focused.  

this message, while written for eiffel, still
applies to ADA-95.  i am very curious to know
how non C++ people handle the following two
scenarios, especially the object-shareing issue.
garbage collection is sold as a feature on most
OO languages totally without context and without
discussing the impact.

thanks very much
shane miller

-------------------------------------------------

hi:

i am trying to examine the possibility of using eiffel
or ADA-95 in place of C++ for a library development project.

the main challege (in this library) has to do with:

	* event driven decision making
	* object sharing and copy-reference semantics

what is the recommended methodolgy under eiffel for these
two scenarios:

SCENARIO 1: event driven "business logic"

	an object of class A wants to change the state
	of an object of class B.  however, B knows that
	it must consult objects from class C and D first
	to see whether the requested change is ok.  B
	knows that it must consult C and D first only
	because C and D found B and registered themselves
	with B saying "if anybody tries to change your
	state you must consult with me first to see if
	i allow it.  if i do not then you cannot make the
	change".  also, an object from class E has found
	object B and says "notify me only if your state
	changes.  i don't care what the change is; just
	notify me after you've changed".  

	ok, A sends a message to B and says "change age
	to 10".  this generates two messages: one event is
	sent to C and one to D saying the "proposed change
	is age<-10, is this ok?".  if both C and D say
	yes, then the age is changed which generates 
	another message: an message is sent to E saying
	"age was changed to 10".

	how does this work under eiffel? (under C++ function
	ptrs, functors, and object references or pointers
	are used for objects A,B,C,D,E).  also, under C++ i
	would have "controller" objects to facilitate the
	messaging and "business objects" to contain things
	like "age".  this is after NeXT's approach of willChange
	and didChange messages plus controller objects which delegate
	work to business objects.

SENCARIO 2: object sharing and object copying.

	you are writing a library.  in your library you maintain
	a very important list.  each item in the list is large
	say around 5K.  you have another list also very importnat
	which contains around 100K items but each item is real
	small, say, around 50 bytes.

	these lists are important so you need to make them
	available to client programmers who might want to
	inspect them or make a computation based on them.

	Question 1: how do you make each list available to a
	client programmer without allowing the client programmer
	to change the list or the state of a object in the list?
	this is important because changing the list could have
	a big impact on the rest of the items in the list (eg.
	the list is sorted; the list is spatial).  so the only
	way a client can alter the list is to make another library
	call in which the list is changed as a side effect.

	Question 2: the user for a computation needs to obtain
	a copy one of the lists.  he needs to do this so he can
	change the state of an object or two and then update a
	result in some part of his program.  how can the client
	programmer get a copy of the list with a minimum of a
	performance hit?

	(in C++ we would implement question 1 using a iterator
	allowing the client programmer to call "const" only 
	functions and const only functions on the list's contents.
	therefore with no copying he has read-only access to the
	list [in C++ he could cast away the const and do something
	wrong too].  for question 2, we would implement the object
	in the list using reference counting and copy-on-write.
	so if the user wanted a copy of the short-list but with
	big objects, only the objects he *ACTUALLY CHANGED* got
	copied; all the others are still have a reference to the
	libraries version.  same with the long list but with
	small objects.  in either case only the energy which is
	needed is actually expended).

i hear a lot of "bravo " about garbage collection in eiffel
but i never hear anything on these real major-league problems.

i have order the eiffel book whicj talks about library
development.  i will very interested in reading what it says
about this crtical problem in library design.  obviously
this critical not only for the library designer by the 
client programmer too
-- 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

Re: READ 1ST: use eiffel for CAM library development?

[Nick Roberts]

Answering on behalf of the Ada group ...

The things you want done can be done in Ada no problemo.  I would be happy
to show you how, in detail, if you require.  Furthermore, what you want
could be done in Ada a lot better than in C++; again, I can explain this in
detail as you require.

I gather that garbage collection tends not be implemented by default by
most Ada compilers.  Fortunately, however, Ada 95 (the current standard)
provides a way for the programmer to provide garbage collection in a
relatively convenient way.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Shane Miller <shanem@netcom.com> wrote in article
<shanemEn5rG0.54A@netcom.com> at length about the suitability of Eiffel and
Ada for a certain task.

Re: READ 1ST: use eiffel for CAM library development?

[Brian Rogoff]

On 22 Jan 1998, Nick Roberts wrote:
> I gather that garbage collection tends not be implemented by default by
> most Ada compilers.  Fortunately, however, Ada 95 (the current standard)
> provides a way for the programmer to provide garbage collection in a
> relatively convenient way.

If you mean using controlled types to implement reference counting, that
is really not the same as garbage collection because it will not allow 
cyclic structures to be reclaimed, though that may not be important in
some applications. I remember discussing using System.Storage_Pools for
this purpose before, but I don't think that is quite up to the task
either, though it can be used to implement lots of other memory
reclamation policies. If you need GC in Ada, your best best for now is to
use one of the Ada -> Java Virtual Machine compilers. 

It certainly would be much easier to build a GC for Ada than for C++, but 
I don't know if anyone has gotten around to it yet. 

-- Brian

Re: READ 1ST: use eiffel for CAM library development?

[Matt Kennel]

On Wed, 21 Jan 1998 23:48:00 GMT, Shane Miller <shanem@netcom.com> wrote:
:
:	Question 1: how do you make each list available to a
:	client programmer without allowing the client programmer
:	to change the list or the state of a object in the list?

    You would pass back a type of

         READ_ONLY_LIST[ READ_ONLY_T]

where READ_ONLY_LIST and READ_ONLY_T were an abstract supertypes above the
concrete implementation of the list and list element classes, which did not
provide public features which modify their data storage.

Remember, that's all that C++ 'const' really is---it's a type modifier
which takes an existing type and creates one with some 'writing'
features removed.  It is way uglier than just explicitly using
abstract superclasses which perform the same function.


:	this is important because changing the list could have
:	a big impact on the rest of the items in the list (eg.
:	the list is sorted; the list is spatial).  so the only
:	way a client can alter the list is to make another library
:	call in which the list is changed as a side effect.
:

:	Question 2: the user for a computation needs to obtain
:	a copy one of the lists.  he needs to do this so he can
:	change the state of an object or two and then update a
:	result in some part of his program.  how can the client
:	programmer get a copy of the list with a minimum of a
:	performance hit?

There would be a member function:  return_copy_of_list with
a return value LIST[ READ_WRITABLE_T]  where READ_WRITABLE_T would
be a type which allowed mutable access.  The function would have
to decide whether it wanted to provide a shallow or deep copy.


:for question 2, we would implement the object
:	in the list using reference counting and copy-on-write.
:	so if the user wanted a copy of the short-list but with
:	big objects, only the objects he *ACTUALLY CHANGED* got
:	copied; all the others are still have a reference to the
:	libraries version.  same with the long list but with
:	small objects.  in either case only the energy which is
:	needed is actually expended).

No problem. Do the same thing.  The 'return_copy_of_list' function would
return a predominantly "shallow copy" of LIST[ COPY_ON_WRITE_T ], where the
COPY_ON_WRITE_T class presented a similar public interface as T, but
implemented the copy-on-write semantics upon mutation.

E.g. it had an internal pointer to the shared 'T', but any mutation causes
storage for new data to be allocated, and the pointer set to nil, or
if you're willing to use RTTI, altered to point to the data storage class
COPIED_ON_WRITE_T so shared vs copied objects could be distinguished. 

No reference count needed, standard GC works.

:-- 
:--------------------------------------------------------------------
: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
:--------------------------------------------------------------------


-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* Quoth the X Consortium:         "Mechanism Not Policy"
*
* Translated: "Once ze windows go up, who cares why push MouseDown.  That's
* not my department!" says Wehrner von Braun.