From lieber@ccs.neu.edu Mon Aug  4 23:30:05 1997
Received: from stockberg.ccs.neu.edu (lieber@stockberg.ccs.neu.edu [129.10.112.123])
	by amber.ccs.neu.edu (8.8.6/8.7.3) with ESMTP id XAA06328; Mon, 4 Aug 1997 23:30:01 -0400 (EDT)
From: Karl Lieberherr <lieber@ccs.neu.edu>
Received: (lieber@localhost)
	by stockberg.ccs.neu.edu (8.8.6/8.6.4) id XAA14389; Mon, 4 Aug 1997 23:30:01 -0400 (EDT)
Date: Mon, 4 Aug 1997 23:30:01 -0400 (EDT)
Message-Id: <199708050330.XAA14389@stockberg.ccs.neu.edu>
To: dougo@ccs.neu.edu, jayantha@ccs.neu.edu
Subject: collection class specs.
Cc: batory@cs.utexas.edu, dem@ccs.neu.edu
Status: R

Hi Doug and Josh:

How do you want the Jakarta Team of Don Batory at the
University of Texas generate 
the collection classes so that they integrate
smoothly with the rest of Demeter/Java?

Regarding synchronization, should the COOL aspect descriptions
handle the synchronization also for collection classes?
This will allow us fine-grained synchronization through
mutual-exclusion sets and self-exclusion sets.
I think the monitor concept they have now is also useful
since we cannot generate that kind of code through COOL (Crista
implements even a monitor through a coordination object; so does
Josh,right?)

Yes, we need access by position for some containers.

Please can you improve on my response.

We will get fancy collection classes, such as red-black trees
and the like. Are there some collection classes of immediate use
to speed up Demeter/Java? Which ones would you like to get?
(Remember, Demeter/Java willoffer a library of about 20 collection classes
and the capability to generate more through Jakarta/P3.)

-- Karl

>From dsb@cs.utexas.edu Mon Aug  4 14:54:52 1997
>From: "Don Batory" <dsb@cs.utexas.edu>
>Date: Mon, 4 Aug 1997 13:54:27 -0500
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>Subject: Re:  hi
>Cc: dsb@cs.utexas.edu
>
>I have some questions for you.
>
>(1) here is the concept of "monitor" that we have 
>    implemented.  Is this consistent with your needs?
>
>    A container is a collection of zero or more elements.
>    Access to elements is via cursors, which optionally
>    can have selection predicates (and orderby clauses to
>    enable selected elements to be returned in a particular
>    sorted order).
>
>    A container is "synchronized" (i.e., a monitor) if only
>    one operation can be executed on:
>
>    (a) the container, or
>    (b) any of its elements, or
>    (c) any of its cursors
>
>    at any time.
>
>    Presently, the only operations on elements that are 
>    synchronized are accessors and modifiers.  (I.e.,
>    there is a data member "X", which has an accessor
>    method "X()" (which returns the value of X for the
>    given element) and a modifier method "X(_x)" which
>    updates the value of X to be _x.
>
>    We discovered that a user-defined method on elements,
>    such as:
>
>    void increment() {
>       X( X() + 1 );
>    }
>
>    will *not* be synchronized - i.e., it will be executed
>    as the sequence of two atomic operations - the accessor
>    X() and the modifier X( _original_X + 1).  We can make
>    all user-defined methods atomic too, but have not done
>    so.  Do you need this extra capability?
>
>(2) Do you need to access elements by position (i.e., return
>    the ith element in the container)?  Presently, we don't
>    have this capability, but it shouldn't take more than
>    a week to add it.  (We were planning on adding it anyway).
>
>
>Don
>
>