Alpha release of Collection Library for GNU Objective-C

Alpha release of Collection Library for GNU Objective-C

Post by R. Andrew McCall » Thu, 03 Jun 1993 04:58:27

Alpha Release of the Collection Library for GNU Objective-C

WARNING: This library has not been tested, and I would be surprised if
it were usable at this point.  I am making it public now in order to
get feedback on design issues.  A further warning: The API may still
change before the first official release---if you write code based on
this library you may later have to update your code to match.

* Where can you get it?  How can you compile it?

By anonymous ftp at,
where ?????? is some string of numbers specifying its date.

The library requires gcc-2.4.0 or higher.

* What is the Collection library?

It's a library of Objective-C objects with similar functionality to
Smalltalk's Collection objects.  It includes: Set, Bag, Array,
LinkedList, LinkList, CircularArray, Queue, Stack, Heap, SortedArray,
MappedCollector, GapArray and DelegateList.

Outside of its main heirarchy it also includes List, HashTable and
Storage objects compatible with NeXT's objects of the same name.

This release also includes a very preliminary version of a String
object.  I threw it together mostly as a thought-experiment to make
sure that my changes to the IndexedCollection abstract superclass
would fit well with a String class.  Many methods are left
unimplemented; it is not useable.

As an extra plus, the .tar file includes classes Magnitude and Time.
Eventually the .h files for these will be moved outside of the "coll"

See the ChangeLog for notes about the differences between this release
and the last.

The library is built around several protocols: Here are some explanatory
comments from the protocol .h files:

   The <Collecting> protocol is root of the collection protocol heirarchy.
   The <Collecting> protocol defines the most general interface to a
   collection of elements.  Elements can be added, removed, and replaced.
   The contents can be tested, enumerated, and copied with various
   modifications.  Elements may be objects, or any C type included in the
   "elt" union given in elt.h, but all elements of a collection must be of
   the same C type.  You may also specify the function used to compare
   [NOTE: for examples see Set and Bag.]

   The <KeyedCollecting> protocol inherits from the <Collecting> protocol.
   The <KeyedCollecting> protocol defines the interface to a
   collection of elements that are accessible by a key, where the key is
   some unique element.  Pairs of (key element, content element) may be
   added, removed and replaced.  The keys and contents may be
   tested, enumerated and copied.
   [NOTE: for examples see Dictionary and MappedCollector.]

   The <IndexedCollecting> protocol inherits from the
   <KeyedCollecting> protocol.
   The <IndexedCollecting> protocol defines the interface to a
   collection of elements that are accessible by a key that is an index,
   where the indeces in a collection are a contiguous series of unsigned
   integers beginning at 0.  This is the root of the protocol heirarchy
   for all collections that hold their elements in some order.  Elements
   may be accessed, inserted, replaced and removed by their index.
   [NOTE: for examples see Array and LinkList.]

   The <ListLinking> protocol defines the interface to an object
   that may be an element in a LinkList.  LinkList is a collection
   object based on a doubly linked list.
   [NOTE: for an example see ListLink.]

Here is the object inheritance heirarchy.  All collection abtract
superclasses (classes which are not usable without subclassing) end
with "Collection"; all protocols end with "ing"; all collection
protocols end with "Collecting".

   Collection <Collecting>
       KeyedCollection <KeyedCollecting>
           IndexedCollection <IndexedCollecting>
    ListLink <ListLinking>
    IdListLink <ListLinking>


* The design philosophy.

Objective C is not Smalltalk.  Differences that matter to the
Collection heirarchy:

- There can be only one set of argument types with each selector.
(For instance in Objective-C we can't have "-(double)data" and
"-(char)data".  I can't stand it when some library that I'm forced to
load already defines a selector that I want to use with different
types.)  This isn't an issue in Smalltalk because everything is an

* I make the Collection method names a little more descriptive, while
keeping them close to Smalltalk.  (For instance I think there is a
good reason for using "-addObject:" instead of "-add:")

- We will want collections of int's, float's, and other non-Objects.
Using Objective C wrappers around these C primitive types (i.e.
Integer and Float objects) is not an efficient enough option for all

* We could create two parallel heirarchies, one for Objects and one
for elements passed as void*, but since so much of the functionality
overlaps, I have merged them, and it doesn't actually look all that

- Objective C doesn't have Smalltalk Blocks.

* Passing selectors and pointers to functions are both reasonable
substitutes.  I make both options available.  They are distinguished
as "-detectByCalling:" and "-detectByPerforming:", for example.

- Smalltalk does automatic garbage collection; Objective C doesn't.

* I think it should be made obvious which methods allocate a new
object.  Hence "-shallowCopyAs:[Bag class]" instead of
"as:[Bag class]", and "-shallowCopySelect..." instead of "-select...".

- We have usable Collection classes (Set, Bag, Array, etc) with
functionality matching Smalltalk's objects, but there are good
reasons for not having the abstract superclass structure match
Smalltalk exactly.

* If you have any suggestions or bug reports, please contact:

Computer Science Department   UUCP: uunet!!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625