From mccallum Mon Apr  5 12:48:13 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Collection library

Hi Kresten,

I'm willing to work on a Collection library.  I just want to make sure
that I'm not duplicating work.  I think you had mentioned that you had
started a Collection library.  Would you like me to take it over (you
seem so busy with all these other issues).  Or, if you wanted I could
just help you out with parts of it.

In any case, I'd love to see what you've got so far.

- Andrew

From mccallum@cs.rochester.edu Sun Apr 11 15:38:41 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA03808; Sun, 11 Apr 93 15:38:37 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA28178; Sun, 11 Apr 93 15:38:32 -0400
Received: from cayuga.cs.rochester.edu by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA23009@churchy.gnu.ai.mit.edu>; Sun, 11 Apr 93 14:54:14 -0400
Received: from vein.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA28106; Sun, 11 Apr 93 14:54:05 -0400
Received: by vein.cs.rochester.edu (5.61/x) id AA20507; Sun, 11 Apr 93 14:54:03 -0400
Message-Id: <9304111854.AA20507@vein.cs.rochester.edu>
In-Reply-To: <199304111329.AA29361@xiv.iesd.auc.dk>
From: mccallum@cs.rochester.edu
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: gnu-objc@gnu.ai.mit.edu
Subject: A Collection heirarchy
Date: Sun, 11 Apr 93 14:54:03 -0400

Hi Kresten,

I don't have time at the moment to write everything I wanted to say
about Collection object issues, but here is a start:

---------- 8< -------------
A Smalltalk-like Collection heirarchy for Objective C

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
object. 

* I propose to make the Collection method names a little more
descriptive, while keeping them as close to Smalltalk as possible.
(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
cases. 

* We could create two parallel heirarchies, one for Objects and one
for elements passed as void*, but so much of the functionality
overlaps, I propose that we merge them.  From what I've tried so far
it doesn't actually look all that bad.


- Objective C doesn't have Smalltalk Blocks.  

* Passing selectors and pointers to functions are both reasonable
substitutes.  I propose making both options available.  They are
distinguished as "-detectByFunc:" and "-detectBySel:" for example.


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

* I think it should be made more obvious which methods allocate a new
object.  Hence "-copyAsBag" instead of "asBag", and "-copySelect..."
instead of "-select...". 


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

* <<Supporting evidence not explained yet.>>


NOTES:

Could do everything with methods named "...Element", but having some
parallel methods named "...Object" saves the programmer from having to
cast return values, and it might be a little more esthetically
pleasing.  It will also allow code written for a NeXT to port more
nicely.  (Our Array class could respond to a superset of methods from
NeXT's List class.)

---------- 8< ------------


Here's the current state of Collection.h.  I've looked at Smalltalk,
the NIHCL (National Institutes of Health C++ class library which
includes a Collection heirarchy), the collection heirarchy inside of
Diagram2.0 (it's quite exciting! take a look at FCCollection and its
subclasses using AppInspector), and at NeXT's collection objects.

BTW, I've send email to the people at Lighthouse Design three times
asking them about the possibility of donating their FCCollection
classes to GNU, but I've gotten no reply.


--------- 8< ----------
#include <objc/Object.h>

typedef void (*CollectionFunc)(void *);
typedef BOOL (*BoolCollectionFunc)(void *);
typedef id (*IdCollectionFunc)(void *);
typedef void (*CollectionFunc2)(void *, void *);

@interface Collection : Object
{
    char *_description;
}

/* Instance creation */
+ with:(void *)anElement;
+ with:(void *)firstElement with:(void *)secondElement;
+ with:(void *)firstElement with:(void *)secondElement 
    with:(void *)thirdElement;

/* Initializing and freeing */
- initCapacity: (unsigned)aCapacity description:(const char *)type
- initCapacity: (unsigned)aCapacity;
- initDescription:(const char *)type
- init;
- free;
- freeElements;

/* Adding */
- addElement: (void *)newElement;
- addElementIfAbsent: (void *)newElement;
- addElementsFrom: (id <Collection>)aCollection;
- addElementsIfAbsentFrom: (id <Collection>)aCollection;

/* Removing and replacing */
/* What should be returned for all these methods? */
- (void *) removeElement: (void *)oldElement;
- (void *) removeAllOccurancesOfElement: (void *)oldElement;
- (void *) removeElementsIn: (id <Collection>)aCollection;
- removeElementsNotIn: (id <Collection>)aCollection;
- replaceElement: (void *)oldElement with: (void *)newElement;
- replaceAllOccurancesOfElement: (void *)oldElement with: (void *)newElement;
- empty;

/* Testing */
- (BOOL) includesElement: (void *)anElement;
- (BOOL) includesSubsetOf: (id <Collection>)aCollection;
- (BOOL) includesSameContentsAs:  (id <Collection>)aCollection;
- (BOOL) isDisjointFrom: (id <Collection>)aCollection;
- (BOOL) isEmpty;
- (unsigned) occurrencesOf: (void *)anElement;
- (BOOL) trueForAllByFunc: (BoolCollectionFunc)aFunc;
- (BOOL) trueForAllBySel: (SEL)aBoolSel;
- (BOOL) trueForAllBySel: (SEL)aBoolSel with: (void *)argElement;
- (BOOL) trueForAllBySel: (SEL)aBoolSel in: selElement;
- (BOOL) trueForAllBySel: (SEL)aBoolSel in: selElement 
	with: (void *)argElement;
- (BOOL) trueForAnyByFunc: (BoolCollectionFunc)aFunc;
- (BOOL) trueForAnyBySel: (SEL)aBoolSel;
- (BOOL) trueForAnyBySel: (SEL)aBoolSel with: (void *)argElement;
- (BOOL) trueForAnyBySel: (SEL)aBoolSel in: selObject;
- (BOOL) trueForAnyBySel: (SEL)aBoolSel in: selObject 
	with: (void *)argElement;

/* Iterating */
- doByFunc: (CollectionFunc)aFunc untilYes:(BOOL *)flag;
- doByFunc: (CollectionFunc)aFunc;
- doOnShallowCopyByFunc: (CollectionFunc)aFunc untilYes:(BOOL *)flag;
- doOnShallowCopyByFunc: (CollectionFunc)aFunc;
- doBySel: (SEL)aSel;
- doBySel: (SEL)aSel with: (void *)argElement;
- doBySel: (SEL)aSel in: selObject;
- doBySel: (SEL)aSel in: selObject with: (void *)argElement;
- makeObjectsPerform: (SEL)aSel;
- makeObjectsPerform: (SEL)aSel with: (void *)argElement;

/* Copying */
- shallowCopy;
- shallowCopyAs: aCollectionClass;
- deepen;

/* Copying enumerators */
- copySelectByFunc: (BoolCollectionFunc)aFunc;
- copySelectBySel: (SEL)aBoolSel;
- copySelectBySel: (SEL)aBoolSel with: (void *)argElement;
- copySelectBySel: (SEL)aBoolSel in: selObject;
- copySelectBySel: (SEL)aBoolSel in: selObject with: (void *)argElement;
- copyRejectByFunc: (BoolCollectionFunc)aFunc;
- copyRejectBySel: (SEL)aBoolSel;
- copyRejectBySel: (SEL)aBoolSel with: (void *)argElement;
- copyRejectBySel: (SEL)aBoolSel in: selObject;
- copyRejectBySel: (SEL)aBoolSel in: selObject with: (void *)argElement;
- copyCollectByFunc: (IdCollectionFunc)aFunc;
- copyCollectBySel: (SEL)aSel;
- copyCollectBySel: (SEL)aSel with: (void *)argElement;
- copyCollectBySel: (SEL)aSel in: selObject;
- copyCollectBySel: (SEL)aSel in: selObject with: (void *)argElement;

/* Non-copying enumerators */
- (void *) detectByFunc: (BoolCollectionFunc)aFunc;
- (void *) detectBySel: (SEL)aBoolSel;
- (void *) detectBySel: (SEL)aBoolSel with: (void *)argElement;
- (void *) detectBySel: (SEL)aBoolSel in: selObject;
- (void *) detectBySel: (SEL)aBoolSel in: selObject with: (void *)argElement;
- inject: (void *)initialData byFunc: (IdCollectionFunc2)aFunc;
- inject: (void *)initialData bySel: (SEL)aSel into: selObject;

- uniqueElements;

@end
--------- 8< ----------

The only subclass responsibilities are 
- addElement;
- removeElement;
- doByFunc:untilYes:
although obviously will will want to override some of these for
efficiency; and obviously we will add more methods in subclasses such
as SeqCollection.

I welcome any and all suggestions, comments, complaints about
completely wrong approach, etc...

Regards,
	Andrew

P.S.  Kresten, I've made some changes to my List object because it
wasn't actually compatible with NeXT's List object in several ways.  I
was going to release my changes, but I wanted to test it a little more
before I did so.  Do you have any code for testing List's and
HashTable's?

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From krab@iesd.auc.dk Sun Apr 11 15:57:37 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA04394; Sun, 11 Apr 93 15:57:33 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA28224; Sun, 11 Apr 93 15:57:30 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA13745
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sun, 11 Apr 1993 21:51:27 +0200
Received: by xiv.iesd.auc.dk id AA00947
  (5.65c8/IDA-CLIENT/MD); Sun, 11 Apr 1993 21:51:51 +0200
Message-Id: <199304111951.AA00947@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
Subject: Re: A Collection heirarchy
Date: Sun, 11 Apr 1993 21:51:51 +0200

I've used this sunday for cleaning up / rewriting my collection
library.  This is pretty close to Smalltalk, although I've not made a
nice inheritance hierachy -- I intend to make a nice protocol hierachy
instead.  I hope to make a *alpha alpha* release version -200 later
today, and then we could discuss details relative to that -- I'm open
for throwing the whole thing away if that's really desireable :-)

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

This is a good idea.  I'll follow this.

  * We could create two parallel heirarchies, one for Objects and one
  for elements passed as void*, but so much of the functionality
  overlaps, I propose that we merge them.  From what I've tried so far
  it doesn't actually look all that bad.

Hmm.  I don't really like this -- a lot of code will be obscured and
slowed down by this.  I'd rather make seperate classes e.g.
IdArray vs StringArray, and then live with the copying of code.  It is
somewhat important that the code is clean and efficient, as it'll be
an example for newcomers.

  * Passing selectors and pointers to functions are both reasonable
  substitutes.  I propose making both options available.  They are
  distinguished as "-detectByFunc:" and "-detectBySel:" for example.

This is ok -- I already use local (nested) functions a lot in my code.
This makes the code very neat, e.g. the generic implementation of `-select':

 - select: (SEL)aSelector
 {
   id newCollection = [[self species] new];
   void doSelect (id elem) 
     {
       if ([elem perform: aSelector])
         [newCollection add: elem];
     }
 
   [self withElementsCall: doSelect];
   return newCollection;
 }  


   - We should have usable Collection classes (Set, Bag, Array, etc) with
   functionality matching Smalltalk's objects, but there may be good
   reasons for not having the abstract superclass structure match
   Smalltalk exactly.
   * <<Supporting evidence not explained yet.>>

Well, good arguments are efficiency.  The classes can still have nice
conceptual associations via protocols.

/Kresten

From krab@iesd.auc.dk Sun Apr 11 18:50:46 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA09418; Sun, 11 Apr 93 18:50:42 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA28568; Sun, 11 Apr 93 18:50:38 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA14633
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 12 Apr 1993 00:46:39 +0200
Received: by xiv.iesd.auc.dk id AA01811
  (5.65c8/IDA-CLIENT/MD); Mon, 12 Apr 1993 00:47:02 +0200
Message-Id: <199304112247.AA01811@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
Subject: Collection library
Date: Mon, 12 Apr 1993 00:47:02 +0200

If anyone would like to comment it, here's something on my collection
library.  

The following is the interface specs

@protocol Collection

// ALLOCATION/MANAGEMENT
+ newCapacity: (unsigned)initialSize;
- initCapacity: (unsigned)initialSize;
- freeContents;

// Create a new collection initially containing specified object(s)
+ withObject: anObject;
+ withObject: firstObject with: secondObject;

// ADDING
- addObject: anObject;
- addAllObjects: aCltn;

// REMOVING
- removeObject: anObject;
- removeAllObjects: aCltn;

// TESTING
- (BOOL)isEmpty;
- (BOOL)includesObject: anObject;
- (unsigned) occurrencesOfObject: anObject;

// ACCESSING
- (unsigned) size;

// ENUMERATION

// Send aSelector to each object in the collection.
- makeObjectsPerform: (SEL)aSelector;
- makeObjectsPerform: (SEL)aSelector with: anObject;

// Send aSelector to anObject with argument each object in turn.
- withObjectsPerform: (SEL)aSelector on: anObject;
- withObjectsPerform: (SEL)aSelector on: anObject with: secondObject;

// Apply aFunction to each object in the collection
- withObjectsCall: (void(*)(id)) aFunction;
- withObjectsCall: (void(*)(id, id)) aFunction with: anObject;

// Return a new collection keeping the results of performing aSelector 
// on each object in turn
- map: (SEL)aSelector;
- map: (SEL)aSelector with: anObject;

// Return the first object which answers "YES" when sent the selector 
// aSelector.  Otherwise return nil. 
- detect: (SEL)aSelector;
- detect: (SEL)aSelector with: anObject;

// Return a new collection of all the objects currently in the receiver, 
// which answers "NO" when sent aSelector
- reject: (SEL)aSelector;
- reject: (SEL)aSelector with: anObject;

// Return a new collection of all the objects currently in the receiver, 
// which answers "YES" when sent aSelector
- select: (SEL)aSelector;
- select: (SEL)aSelector with: anObject;
@end


@protocol MappedCollection <Collection>

// ACCESSING
// Return object mapped by the object aKey
- atObject: aKey;

// Insert anObject mapped by aKey
- at: aKey putObject: anObject;

// Return <Collection>'s containing either all key or value objects 
- objectKeys;
- objectValues;

// ENUMERARTION
// For each value object in turn, call aFunction with that 
// object as argument.  -withObjectsCall has the same behaviour
- withValuesCall: (void(*)(id))aFunction;
- withValuesCall: (void(*)(id, id))aFunction with: anObject;

// For each key object in turn, call aFunction with that 
// object as argument.
- withKeysCall: (void(*)(id))aFunction;
- withKeysCall: (void(*)(id, id))aFunction with: anObject;

// For each key object in turn, send aSelector to that object
- makeKeysPerform: (SEL)aSelector;
- makeKeysPerform: (SEL)aSelector with: anObject;

@end


@protocol SequencedCollection <Collection>

// ACCESSING
// Return object at specified index
- objectAtIndex: (unsigned)anIndex;

// Return index corresponding to anObject
- (unsigned) indexOfObject: anObject;

// ADDING
- atIndex: (unsigned)anIndex putObject: anObject;

// REMOVING
- removeObjectAtIndex: (unsigned)anIndex;
@end


@protocol ArrayedCollection <SequencedCollection>

// ACCESSING
// Get or set the maximum capacity for the ArrayedCollection
- (unsigned) capacity;
- setCapacity: (unsigned)anInteger;

@end

@protocol Link
+ nextLink: aLink;              /* create a Link linked to `aLink' */
- nextLink;                     /* return next link */
- nextLink: aLink;              /* assign next link */
@end



The following classes are currently present.  All classes manipulate
*objects* only.  I've not written anything to handle simple types yet.

Collection <Collection>
  Abstract class, which implements "generic" methods.  It
  cannot actually contain anything ...

Set <Collection>
  Can contain one of each object.  Elements are kept in
  a hash table.

Bag <Collection>
  Can contain several of each object.  Elements are kept
  in a hash table mapping object to number of occurrences.

Dictionary <MappedCollection>
  Maps key objects to value objects.  This is mostly 
  like a hash table.

LinkList <SequencedCollection>
  A singly linked list of objects conforming to the <Link>
  protocol.  That is in principle objects inheriting "Link"
  This makes house keeping a lot cheaper.

LinkedList <SequencedCollection>
  A singly linked list of any kind of objects.  

Array <ArrayedCollection>
  A simple "List" like collection.  

If you want the sources you can pick them up from iesd.auc.dk:
/pub/ObjC/libcoll.tar.z.   You cannot compile it though, since it uses
features of GNU Objective C not yet public available -- soon to come!

I have not tested it at all -- this is "rough source", but I'll go to
bed now, so hopefully there'll be some comments tomorrow :-)

Comments appreciated!

/Kresten


From mccallum@cs.rochester.edu Sun Apr 11 22:57:37 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16865; Sun, 11 Apr 93 22:57:33 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA29017; Sun, 11 Apr 93 22:57:29 -0400
Received: from cayuga.cs.rochester.edu by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA26525@churchy.gnu.ai.mit.edu>; Sun, 11 Apr 93 22:19:12 -0400
Received: from vein.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA28973; Sun, 11 Apr 93 22:19:09 -0400
Received: by vein.cs.rochester.edu (5.61/x) id AA23109; Sun, 11 Apr 93 22:19:08 -0400
Message-Id: <9304120219.AA23109@vein.cs.rochester.edu>
In-Reply-To: <199304112247.AA01811@xiv.iesd.auc.dk>
From: mccallum@cs.rochester.edu
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: Collection library
Date: Sun, 11 Apr 93 22:19:08 -0400

Hi Kresten,

I'm glad that we're both working on Collection class issues.  I'm also
open to throwing my whole thing away if it turns out that it's
desirable.  Whichever way we end up going in the end, I think that
we'll finish with a better result by hacking out more than one
experimental implementation.

I think our biggest point of difference is in the "Collections holding
arbitrary 32-bit quantities" vs "Separate Collection classes for
different non-objects".

My idea is based on NeXT's HashTables.  They aren't too ugly, and it
sure would be a pain if you had to use a different class for each key
type (integers, floats, char*'s, etc).

The implementation overlap between collections of objects and
non-objects is phenomenal!  The great majority of my code doesn't even
have to know if the element it is dealing with is an object or not.
The places where the two are treated differently is mostly
encapsulated in the Collection instance's "compare" and "hash"
functions (just like HashTable).  The only other place it matters is
in some error checking for things like "makeObjectsPerform:" to make
sure that the Collection does hold objects.


You didn't comment on my proposal for discriminating methods
that return new copies.  I think it may get pretty confusing to look
at the result of a "select:" getting freed, when beginners are trained
to expect that most methods return self (unless the method name makes
you think otherwise).  Using these names exactly as used in Smalltalk
is only going to make the former Smalltalk users feel at home, but
Smalltalk doesn't even have a concept of freeing.


A few comments on your last message:

* I like your idea of using a heirarchy of protocols.

* I would think that we would want to pass functions with "select:",
and its cousins.  It may be rare that the objects in the collection
happen to respond to some boolean method with just the features we are
interested in.  As I mentioned before, I think providing for selectors
as well is a good idea.

* What's the reason for putting a reference to "capacity" in the base
Collection protocol?  They are not relevant to LinkedList's at all,
for instance.  (This seems like a leftover from Smalltalk Object's
indexed instance vars?)

* ' just wondering why you used the name "map:" instead of "collect:"
("collect:" would match with Smalltalk, as do the rest of your select,
reject, and detect methods.)

* I notice your Link and LinkList stuff.  Does this mean you are doing
object creation / destruction each time you do an add or remove to that
collection?  I know that Smalltalk has Link objects, but do we really
want to do this in Objective C?

** I think we may have slightly different approaches to this
implementation.  Perhaps the difference I'm thinking of was shown most
clearly when you said, "It is somewhat important that the code is
clean and efficient, *as it'll be an example for newcomers.*"
[emphasis mine].  I believe we should implement the Collection
heirarchy to be as efficient and powerful as possible; and the best
implementation may not end up being the perfect example of Objective C
*for newcomers*.  We can distribute other example programs for that.

For example, the "Link" objects are a great example of OO programming
for beginners to study, but I don't think they are the most efficient
way to implement LinkedList's for Objective C.  Having our Collection
classes hold arbitrary 32-bit quantities may not produce the best
Objective tutorial, but they would be powerful and efficient.


Again, I welcome any and all suggestions, comments, complaints.

Regards,
	Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From burchard@geom.umn.edu Mon Apr 12 13:28:03 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA10990; Mon, 12 Apr 93 13:27:59 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/x) id AA01325; Mon, 12 Apr 93 13:27:57 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Mon, 12 Apr 1993 12:24:36 -0500
Message-Id: <9304121724.AA04796@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Mon, 12 Apr 93 12:24:35 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: burchard@geom.umn.edu
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: mccallum@cs.rochester.edu, gnu-objc@gnu.ai.mit.edu
Subject: Re: Collection library
Date: Mon, 12 Apr 93 12:24:35 -0500

One thing that would probably be a good addition to the collection  
protocols---in light of the archiving dilemmas encountered by others  
with the List class---would be ways to specify whether the collection  
owns the objects in it or not:

 - setOwner:(BOOL)flag;  // default is NO
 - (BOOL)isOwner;

isOwner==YES would imply:

 * freeing the collection frees any objects remaining in it
 * archiving the collection writes the objects it contains directly 

    (not as references)
 * copying the collection does one of the following, as appropriate
    (in its -deepen method, which checks if isOwner==YES):
	-- copies the objects inside it
	-- adds a reference count to the objects inside it
	-- makes the copied collection non-owner

As usual, this issue is a side effect of not having garbage  
collection.

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

From pages!kevin@uunet.UU.NET Mon Apr 12 15:38:09 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA14059; Mon, 12 Apr 93 15:38:02 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA01942; Mon, 12 Apr 93 15:37:59 -0400
Received: from relay2.UU.NET by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA05658@churchy.gnu.ai.mit.edu>; Mon, 12 Apr 93 14:44:46 -0400
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA26591; Mon, 12 Apr 93 14:42:37 -0400
Received: from pages.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 143654.771; Mon, 12 Apr 1993 14:36:54 EDT
Received: from planet10 by pages.com (NX5.67c/NX3.0M)
	id AA08967; Mon, 12 Apr 93 11:31:56 -0700
Message-Id: <9304121831.AA08967@pages.com>
Received: by planet10. (NX5.67c/NX3.0X)
	id AA00357; Mon, 12 Apr 93 11:31:56 -0700
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: Kevin Sven Berg <pages!kevin@uunet.UU.NET>
To: gnu-objc@gnu.ai.mit.edu
Subject: re: Collection library
Date: Mon, 12 Apr 93 11:31:56 -0700

re: "setOwner:" proposal

We've taken the approach of providing a "write contents as reference" function
when dealing with lists. This requires no extra storage in the collection
object (important when you get lots of them), and the implementor can use
either type of function. It also is somewhat like what Kresten proposed...

NXWriteObject            <-> NXReadObject
NXWriteObjectReference   <-> NXReadObjectReference   (must match; KKT proposal)
WriteReferenceList       <-> ReadReferenceList       **

Comments?

Kevin

From athan@object.com Mon Apr 12 16:55:17 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA15944; Mon, 12 Apr 93 16:55:11 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA02226; Mon, 12 Apr 93 16:55:07 -0400
Received: from relay1.UU.NET by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA06815@churchy.gnu.ai.mit.edu>; Mon, 12 Apr 93 16:07:59 -0400
Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA15299; Mon, 12 Apr 93 16:06:12 -0400
Received: from lissie.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160517.23502; Mon, 12 Apr 1993 16:05:17 EDT
Received: from swing by lissie.object.com (NX5.67c/NeXT-2.0abc)
	id AA20632; Mon, 12 Apr 93 15:21:35 -0400
Received: by  swing.object.com  (NX5.67c/NeXT-2.0)
	id AA01440; Mon, 12 Apr 93 15:21:34 -0400
Message-Id: <9304121921.AA01440@ swing.object.com >
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: athan@object.com (Andrew Athan)
To: Kevin Sven Berg <uunet!pages!kevin@uunet.UU.NET>
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: Collection library
Date: Mon, 12 Apr 93 15:21:34 -0400

Kevin Sven Berg writes:
> NXWriteObject            <-> NXReadObject
> NXWriteObjectReference   <-> NXReadObjectReference   (must match; KKT  
proposal)
> WriteReferenceList       <-> ReadReferenceList       **
> 


What is NXReadObjectReference?  It does not exist in the NeXT AppKit.  I  
don't see a need for a "ReadObjectReference" function--NXReadObject can be  
implemented such that it returns the same id for all references to some  
object from the same stream.

Andrew Athan
Objective Technologies, Inc.

From burchard@geom.umn.edu Mon Apr 12 17:34:57 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16793; Mon, 12 Apr 93 17:34:51 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA02367; Mon, 12 Apr 93 17:34:47 -0400
Received: from cameron.geom.umn.edu by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA07157@churchy.gnu.ai.mit.edu>; Mon, 12 Apr 93 16:52:22 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Mon, 12 Apr 1993 15:20:51 -0500
Message-Id: <9304122020.AA04893@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Mon, 12 Apr 93 15:20:45 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: burchard@geom.umn.edu
To: Kevin Sven Berg <pages!kevin@uunet.UU.NET>
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: Collection library
Date: Mon, 12 Apr 93 15:20:45 -0500

> We've taken the approach of providing a "write contents
> as reference" function when dealing with lists. This
> requires no extra storage in the collection object 


This is fine as long as everyone handling lists "knows" which lists  
are supposed to be treated as a reference lists and which are not.   
But that wouldn't seem to be the case in many situations; for example  
if the list is passed as a parameter in a distributed object message.  


If the extra storage is painful, you can always just make one type of  
list be a subclass of the other.  (This is, after all, another  
version of the old problem of losing static type information.)

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

From pages!kevin@uunet.UU.NET Mon Apr 12 17:45:24 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16953; Mon, 12 Apr 93 17:45:17 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA02396; Mon, 12 Apr 93 17:45:14 -0400
Received: from relay1.UU.NET by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA07567@churchy.gnu.ai.mit.edu>; Mon, 12 Apr 93 17:11:07 -0400
Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AB05573; Mon, 12 Apr 93 17:08:33 -0400
Received: from pages.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 170706.10022; Mon, 12 Apr 1993 17:07:06 EDT
Received: from planet10 by pages.com (NX5.67c/NX3.0M)
	id AA09690; Mon, 12 Apr 93 14:01:30 -0700
Message-Id: <9304122101.AA09690@pages.com>
Received: by planet10. (NX5.67c/NX3.0X)
	id AA00517; Mon, 12 Apr 93 14:01:29 -0700
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: Kevin Sven Berg <pages!kevin@uunet.UU.NET>
To: athan@object.com (Andrew Athan)
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Collection library
Date: Mon, 12 Apr 93 14:01:29 -0700

>>Kevin Sven Berg writes:
>>
>> NXWriteObject            <-> NXReadObject
>> NXWriteObjectReference   <-> NXReadObjectReference (must match; KKT 

>>proposal)
>> WriteReferenceList       <-> ReadReferenceList       **
>>
>
> athan@object.com (Andrew Athan) writes:
>
>What is NXReadObjectReference?  It does not exist in the NeXT AppKit.  I don't  
>see a need for a "ReadObjectReference" function--NXReadObject can be  
>implemented such that it returns the same id for all references to some object  
>from the same stream.

Nope, you won't find it in any NeXT manual. Note that the line is followed
by "proposal". Kresten proposed doing symmetric read/write reference functions.
I proposed exactly the same thing for collections, and gave an example of
how we [Pages] actually are using this symmetry right now for lists 

(last pairing -- the **'s).

regards,

Kevin


From krab@iesd.auc.dk Mon Apr 12 18:30:34 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA17734; Mon, 12 Apr 93 18:30:27 -0400
Received: from churchy.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA02525; Mon, 12 Apr 93 18:30:24 -0400
Received: from iesd.auc.dk by churchy.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA08269@churchy.gnu.ai.mit.edu>; Mon, 12 Apr 93 17:59:14 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA21830
  (5.65c8/IDA-1.5/MD for <gnu-objc@gnu.ai.mit.edu>); Mon, 12 Apr 1993 23:58:22 +0200
Received: by xiv.iesd.auc.dk id AA07240
  (5.65c8/IDA-CLIENT/MD); Mon, 12 Apr 1993 23:58:47 +0200
Message-Id: <199304122158.AA07240@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: gnu-objc@gnu.ai.mit.edu
Cc: krab@iesd.auc.dk
Subject: read_reference
Date: Mon, 12 Apr 1993 23:58:47 +0200

The reson for having matching read/write reference was to make clear
that a reference "read" may not be accessible at once, this is not
guaranteed before -awake is called.  It is not an implementation
issue -- in fact my current implementation doesnt have read_reference
at all.

/Kresten

From krab@iesd.auc.dk Mon Apr 12 19:17:25 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA18684; Mon, 12 Apr 93 19:17:19 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA02626; Mon, 12 Apr 93 19:17:15 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA22364
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Tue, 13 Apr 1993 01:14:06 +0200
Received: by xiv.iesd.auc.dk id AA07462
  (5.65c8/IDA-CLIENT/MD); Tue, 13 Apr 1993 01:14:32 +0200
Message-Id: <199304122314.AA07462@xiv.iesd.auc.dk>
In-Reply-To: <9304120219.AA23109@vein.cs.rochester.edu> (mccallum@cs.rochester.edu)
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: Collection library
Date: Tue, 13 Apr 1993 01:14:32 +0200

   My idea is based on NeXT's HashTables.  They aren't too ugly, and it
   sure would be a pain if you had to use a different class for each key
   type (integers, floats, char*'s, etc).

Ok, I'll look into how to code this.  Should we use "Object" suffix
for id'ish selectors and "Element" for all others?  This way we'll
have typechecking at least on objects...

   Using these names exactly as used in Smalltalk
   is only going to make the former Smalltalk users feel at home, but
   Smalltalk doesn't even have a concept of freeing.

Well, you're right, but "copy" is not the right verb here.. We should
come up with something better.

   * I would think that we would want to pass functions with "select:",
   and its cousins.  It may be rare that the objects in the collection
   happen to respond to some boolean method with just the features we are
   interested in.  As I mentioned before, I think providing for selectors
   as well is a good idea.

Right -- perhaps we should even have 3 variants "selectByPerforming:",
"selectByPerforming:on:" and "selectByCalling:".  The middle one sends
a one-argument message to a singe object with the argument ranging
over the collection members.

   * What's the reason for putting a reference to "capacity" in the base
   Collection protocol?  They are not relevant to LinkedList's at all,
   for instance.  (This seems like a leftover from Smalltalk Object's
   indexed instance vars?)

Well, that's a typo -- "capacity" should only be in the <ArrayedColl>
protocol. 

   * ' just wondering why you used the name "map:" instead of "collect:"
   ("collect:" would match with Smalltalk, as do the rest of your select,
   reject, and detect methods.)

Well, I like "map:" better!  map is the name nown from enywhere else
but Smalltalk.  (That is, diverse functional languages)

   * I notice your Link and LinkList stuff.  Does this mean you are doing
   object creation / destruction each time you do an add or remove to that
   collection?  I know that Smalltalk has Link objects, but do we really
   want to do this in Objective C?

A "LinkList" is a list of objects which respond to "nextLink" (get
next link) and "nextLink:" (set next link).  Thus a "LinkList" does
not do allocation or other management.  A "LinkedList" keeps an
instance of "IdLink" for each element...

   ** I think we may have slightly different approaches to this
   implementation.  Perhaps the difference I'm thinking of was shown most
   clearly when you said, "It is somewhat important that the code is
   clean and efficient, *as it'll be an example for newcomers.*"
   [emphasis mine].  I believe we should implement the Collection
   heirarchy to be as efficient and powerful as possible; and the best
   implementation may not end up being the perfect example of Objective C
   *for newcomers*.  We can distribute other example programs for that.

Ok, we can agree on this -- if we're going to support multi-type
collections, the code is going to be ugly anyway, so who cares...
Let's just go ahead and hack!

/Kresten

From mccallum Tue Apr 13 10:50:44 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199304122314.AA07462@xiv.iesd.auc.dk>
Subject: Re: Collection library

Hi Kresten,

You write:
>   My idea is based on NeXT's HashTables.  They aren't too ugly, and it
>   sure would be a pain if you had to use a different class for each key
>   type (integers, floats, char*'s, etc).
>
>Ok, I'll look into how to code this.  Should we use "Object" suffix
>for id'ish selectors and "Element" for all others?  This way we'll
>have typechecking at least on objects...

Yes, I agree and I already have methods with both names in my
implementation. 

>Right -- perhaps we should even have 3 variants "selectByPerforming:",
>"selectByPerforming:on:" and "selectByCalling:".  The middle one sends
>a one-argument message to a singe object with the argument ranging
>over the collection members.

Yup.  These are *exactly* the method names that I now have in my
implementation. 


Well, now our implementationas are sounding very similar, and I wonder
if we are loosing the benefit of creating two separate test
implementations.  Perhaps now we are just being wasteful.

I would like to ask what you would think of me taking over the
Collection library stuff.

* You already have so much to do with the rest of the Objective C
implementation, and some people may prefer that other Objective C
features such as class variables develop more quickly.

* I've given the Collection library a lot of thought; I'm happy to do
this for GNU.  I will act as a faithful arbiter of ideas from others
about the Collection heirarchy---if there is concensus from you and
others on implementation ideas with which I disagree, my Collection
library will represent the "will of the people."

The last thing I want to do it "step on your toes".  You have done
great work for Objective C, and I have nothing but respect for you.
If you feel very strongly about doing the Collection library yourself,
I guess there's not much that I can do.

Let me know what you think,
	Best regards,
		Andrew

From krab@iesd.auc.dk Tue Apr 13 11:07:39 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA10412; Tue, 13 Apr 93 11:07:35 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA05376; Tue, 13 Apr 93 11:07:30 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA00272
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Tue, 13 Apr 1993 17:06:36 +0200
Received: by xiv.iesd.auc.dk id AA09966
  (5.65c8/IDA-CLIENT/MD); Tue, 13 Apr 1993 17:07:02 +0200
Message-Id: <199304131507.AA09966@xiv.iesd.auc.dk>
In-Reply-To: <9304131450.AA06962@vein.cs.rochester.edu> (mccallum@cs.rochester.edu)
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: Re: Collection library
Date: Tue, 13 Apr 1993 17:07:02 +0200

   I would like to ask what you would think of me taking over the
   Collection library stuff.

You're most welcome.  The reason why I started coding on this was
because I thought you said that you wouldn't have time for it?  I'd
very much like at least an early, but stable, release to be available
with gcc 2.4 in a month or so...

   * You already have so much to do with the rest of the Objective C
   implementation, and some people may prefer that other Objective C
   features such as class variables develop more quickly.

New features will have to wait until after 2.4.  For now, I'll make a
pre-release available ASAP and then do fixes and minor enhancements
only -- until the next release.  I'll be in Moscow next week, so
hopefully the pre-release can be out before then.

   The last thing I want to do it "step on your toes".  You have done
   great work for Objective C, and I have nothing but respect for you.
   If you feel very strongly about doing the Collection library yourself,
   I guess there's not much that I can do.

I don't feel stronly about doing it -- just having it :-) Please go
ahead and code... I can see that you've picked up my libcoll, and
you're most welcome to use whatever you like from that.  I've not made
any noticably changes (at least I don't remember any..) since I put it
there.

Please keep on informing me, and the list, on what you decide to do.
I think it's a good thing that more than one competent programmer has
a word to say on the design.

Kresten

BTW -- Brad Cox sent this to me:

 Suggestion #1: Stick with the standard interface, such as it is. Described
 in my book for a few classes. No doubt Ken Lerman could get y
 Sugestion #2: If you *really*, really can't resist tinkering, consider
 using the phrase "Member" instead of "Object". Thus aI've always regretted not a
 dopting the latter convention for collections
 when I had a chance. But I felt constrained to l
 convention is perfect and unconstrained perfectionism just causes innocent
 users problems without improving anything sub--
	Brad Cox; bcox@gmu.edu; 703 968 8229 Voice 703 968 8798 Fax
	George Mason Program on Social and Organizational Learning


From mccallum Tue Apr 13 11:50:30 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199304131507.AA09966@xiv.iesd.auc.dk>
Subject: Re: Collection library

Hi Kresten,

I accept my mission as Collection heirarchy implementor.  I'm
thrilled to be able to contribute!

I do go through brief periods of busy-ness, but there will not be a
problem with me finishing an early stable release of a Collection
library for gcc 2.4 in about a month from now.

I'll also be happy to periodically send you private releases of the
current state of the library.  I'll be happy to get the feedback.

Re Brad Cox's message:

* Do you have a preference for the word "Member" or "Element" in
method names?

* He says, "Stick with the standard interface as described in his
book."  I assume by the way you started coding your heirarchy that you
don't agree with this.  I don't agree either.  Some differences are
based on the fact his base Cltn class includes an IdArray as an
instance variable for holding the contents---yuck.  I also prefer some
of the NeXT-compatible method names over his:  "empty" instead of
Cox's "emptyYourself", and "makeObjectsPerform:" instead of Cox's
"elementsPerform:".

Best regards,
	Andrew

From mccallum Tue Apr 13 19:35:43 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Object

Hi Kresten,

Just two little things:

* What would you think about adding "-shouldNotImplement:(SEL)aSel" to
Object.  It's in Smalltalk and it's in NeXT's Object (although it
isn't documented).  There have been times that I've found it to be
useful. 

* What do you think about the difference between NeXT's "-superclass"
and our current "-superClass".  If you want to keep "-superClass", we
might still want to add "-superclass" for compatibility with NeXT
programs?  I suppose that their capitalization is more consistent with
the way we write "subclass" not "subClass".

I sent a subscription message to gcc2-request@cygnus.com.  I'm
compiling the latest version of gcc right now.

I should be able to give you a first glance at my Collection code
sometime soon.

Cheers,
	Andrew

From mccallum Mon Apr 19 13:45:12 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199303091128.AA10780@iesd.auc.dk>
Subject: runtime (NOT) - what will it have?

Hi Kresten,

I should be able to send you a first version of the Collection library
this evening.  Welcome back to the net.

- Andrew

Kresten Krab Thorup writes:
 > Pieter Schoenmakers writes:
 > > [list of varous classes...]
 > >I think this is a reasonable beginning of a decent class library.
 > >At least for me it is :-)
 > 
 > In my oppinion, an objective C standard library should be in the
 > spirit of the Smalltalk collection library.  As noted, I have a almost
 > complete library like this (Michael Uhlenberg posted another lately).
 > If someone is willing to finish/test it he/she can have a copy, but
 > not for playing around...  It is not ready for distribution yet.
 > 
 > It takes a good programmer to design a such library, but hopefully a
 > such could be the basis of a lot of other classes, so that they will
 > have a *consistent* interface.
 > 
 > /Kresten


From mccallum Mon Apr 19 17:03:59 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Collection library prelim

Hi Kresten,

My preliminary version of the Collection library can be obtained by
anonymous ftp at

cs.rochester.edu:pub/libcoll-930419.tar.z

It compiles fine, but since I still seem to be having problems getting
the results of gcc to run*, I haven't run any tests on it.  I'm mostly
interested in your comments about functionality and method names
anyway. 

Feel free to send criticism---anything from big picture direction to
little name preferences. 

I'm looking forward to your feedback.

* This is getting really frustrating.  I grabbed the latest
ss-930417.tar.z, configured it for our sparc's, in the Makefile
changed prefix and local_prefix to /u/mccallum/usr, and compiled and
installed it without problems.  But then 'gcc foo.m -lobjc' can't find
libobjc.a, and the linker complains about __eprintf missing.  When I
add the approriate '-L' and a dummy __eprintf, my resulting
executables seg fault in the objc runtime.

I must be doing something silly.  Any suggestions?

Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From krab@iesd.auc.dk Tue Apr 27 14:41:28 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA00987; Tue, 27 Apr 93 14:41:25 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA10847; Tue, 27 Apr 93 14:41:22 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA06931
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Tue, 27 Apr 1993 20:39:38 +0200
Received: by xiv.iesd.auc.dk id AA26734
  (5.65c8/IDA-CLIENT/MD); Tue, 27 Apr 1993 20:40:24 +0200
Message-Id: <199304271840.AA26734@xiv.iesd.auc.dk>
In-Reply-To: <9304271623.AA14573@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Subject: Collection library prelim
Date: Tue, 27 Apr 1993 20:40:24 +0200

  OK.  I'm working on more improvements to the Collection library.  I've
  added preliminary a protocol for collections of objects accessible by
  index, but not insertable by index (like stacks and queues), and a
  protocol (subclass of previous) for sorted collections.

Sounds fine.  My general impression of the collection library is that
it's fine.  Even though there's still a lot of thing top be coded, the
general framework is there.

  If you have any major, big picture suggested changes, it'd be nice to
  hear about them before I do a lot more work building on what I've got
  so far.

I suggest we make some typesafe way to keep any kind of type.  I think
you should make a set of inline functions which manipulate a unioon of
all the allowed types.  This way we can make perfectly sure that
nothing goes wrong.  Casting is far from safe, so this would be
much better.

For special things, such as arrays of things, you could have a
dispatch table, keyed by the encoding, which kept accessing functions.
In principle:

	switch (*_desc) {
	  case '*': ((char**)_data)[index] = *((char**)theValue); break;
	  case 's': ((short*data)[index] = *((short*)theValue); break;
	...
	}

should be distinct functions all accepting a char* as argument.  For
speed, this dispatch table could be an array ranging over all char's,
which keeps function pointers.  Using this, the above is written as:

	(*(put_val_func[*_desc]))(index, &theValue)

Or something like that.

Another matter is that you have very few ...Object, and a lot
...Element in the code.  I expect that you're planning to do them as
well.

/Kresten

From mccallum Thu Apr 29 19:43:53 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Collection library again

Hi Kresten,

Another version of the Objective-C Collection library can be found at
cs.rochester.edu:pub/libcoll-930429.tar.z.

It still lacks a lot of implementation, and hasn't undergone much
testing at all, but there have been a lot of improvements.

Here are some of the key issues for your (and others) feedback.
Soon I think I'll want to show libcoll to others.  Do you have
suggestions as to who?  It'd be nice to include someone from NeXT.

TODO:

* Add archiving.

* Add sorting capabilities.

* Add more classes?

* Obviously, fill in relevant "-notImplemented"

--------------------------------------------------------------------
Questions:

* I've prefixed the names of abstract class with '_'.  I thought that
making it obvious which classes were abstract might be a good idea (so
beginners don't try to create and use them), BUT I could be convinced
that using the '_' was a silly idea.  Any votes for removing or
keeping the underscores?

* What should we do with other classes like 'Time'? (which I've also
implemented) They don't exactly belong in libcoll.  Do we want one big
library of basic Objective-C objects, not a separate libcoll?  I would
like to suggest keeping the runtime and Object implementation separate
from all these other classes, though.

* I've named the protocol for externally ordered sequential
collections "OrdCollecting"  (i.e. users can insert elements at
arbitrary indeces).  Unfortunately, Smalltalk users may get confused
because OrderedCollection is means something different for them.  Does
anyone want to change the name?  Any suggestions?

* The protocol heirarchy has a nice, clean separation between the
sequential collections with internally and externally specified
orders.  We'd like this to show up in the implementation: i.e.
Stack's, Queues, and SortedCollections should not conform to the
OrdCollecting protocol (the one that allows insertion at arbitrary
indeces).  Unfortunately, this causes a little pain in the
implementation---for instance the SeqCollection(ForOrdColleting) and
_BasicArray/Array stuff.  Any complaints or suggestions?

* For names like "shallowCopy[Select,Reject,Collect]ByCalling:" I'm
happy to take suggestions on a replacement for "shallowCopy" if you
can think of something better.

* "-species" method needed?

* What to return on errors?  We need to come up with better error,
warning handling in general for Objective C.

* Every method that has "Element" in the name also has a duplicate
with "Object" in the name (with the types appropriately changed).
This seems like a nice feature---help programmer by avoiding a lot of
casting, and it gives our collection objects methods names familiar to
NeXT programmers.  Would anyone prefer that they not be there?

* I've implemented LinkedLists based on Link objects.  This has the
advantage that the user can nicely get at and manipulate the Links,
however, it also means there is a fair amount of message passing for
east addObject, removeObject, etc.  Anyone want to suggest a different
implementation?   Perhaps something based on an array of structures
that includes indeces of the next element.  This would prevent us from
calling malloc in each insertion.  I'm happy to stick with using
Link's unless someone want to convince me otherwise.


--------------------------------------------------------------------
Changes I'd like in the Objective-C runtime:

* Make objc_sizeof_type() public.

* Add hash_node_for_key() to hash.h and hash.c.

* How about removing cache as a parameter to the hashing functions in
hash.h and hash.c.  Do the masking on the result of the hash function.
This would seem much neater.

* Add -shouldNotImplement to Object.


-- Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625


From krab@iesd.auc.dk Thu Apr 29 20:18:18 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16110; Thu, 29 Apr 93 20:18:14 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA23431; Thu, 29 Apr 93 20:18:08 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA07035
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Fri, 30 Apr 1993 02:16:17 +0200
Message-Id: <199304300016.AA07035@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA26480; Fri, 30 Apr 93 02:17:19 +0200
In-Reply-To: <9304292343.AA28551@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk,
        burchard@geom.umn.edu.Here.are.some.of.the.key.issues.for.your.feedback.Soon.I.think.I'll.want.to.show.libcoll.to.others.Do.you.have.suggestions.as.to.who.It'd.be.nice.to.include.
            (and others)
Subject: Collection library again
Date: Fri, 30 Apr 1993 02:16:17 +0200

Well, why not simply let it out on the gnu-objc list.  If you make it
clear to people that it's a preliminary release noone will really
complain, and you'll have the opportunity to get a larger amount of
input.  I allowed myself to CC this to Paul.
   
   TODO:
   
   * Add archiving.

Wait a while with this, it's fairly easy to do, and we may redo the
archiving stuff if we make up something better.  Besides, we've been
granted an distributed objects system from WilTel, which also may
influence our policy here.

   * Add more classes?

Just do the basic stuf right first.  Once these are done it's more
easy for other people to se how it should be done, and this make your
burden easier :-)
   
   * Obviously, fill in relevant "-notImplemented"

Fill in with implementations ?? :-)
   
   --------------------------------------------------------------------
   Questions:
   
   * I've prefixed the names of abstract class with '_'.  I thought that
   making it obvious which classes were abstract might be a good idea (so
   beginners don't try to create and use them), BUT I could be convinced
   that using the '_' was a silly idea.  Any votes for removing or
   keeping the underscores?

I think this is a silly idea.  Rather give them long names, which
makes them non-user friendly anyway.  
   
   * What should we do with other classes like 'Time'? (which I've also
   implemented) They don't exactly belong in libcoll.  Do we want one big
   library of basic Objective-C objects, not a separate libcoll?  I would
   like to suggest keeping the runtime and Object implementation separate
   from all these other classes, though.

By next gcc release (2.4.something) (some time in the furure) we'll
put what is now libobjc into libgcc, and use libobjc for the "general"
class library.  I think we should have one class library which
includes all generic classes.  For now, we should perhaps keep them
seperated into categories like "os-interface" "collection" etc.  I've
started working on an indexing kit which I'll need for my masters
project, so I believe there'll be plenty of classes to put into a
general purpose class library -- libobjc.
   
   * I've named the protocol for externally ordered sequential
   collections "OrdCollecting"  (i.e. users can insert elements at
   arbitrary indeces).  Unfortunately, Smalltalk users may get confused
   because OrderedCollection is means something different for them.  Does
   anyone want to change the name?  Any suggestions?

Why not invent a new name instead, like "IndexedCollection" -- if the
library looks like the Smalltalk library, alot of people will get
confused if the same name has a radically different meaning.

   * The protocol heirarchy has a nice, clean separation between the
   sequential collections with internally and externally specified
   orders.  We'd like this to show up in the implementation: i.e.
   Stack's, Queues, and SortedCollections should not conform to the
   OrdCollecting protocol (the one that allows insertion at arbitrary
   indeces).  Unfortunately, this causes a little pain in the
   implementation---for instance the SeqCollection(ForOrdColleting) and
   _BasicArray/Array stuff.  Any complaints or suggestions?
   
No complaints.  Just use "-shouldNotImplement:" and the mis-confomance
will turn out at once anyway.  This is a dynamic language right?  I'll
study the hierachies and see if I can make up something better.

   * For names like "shallowCopy[Select,Reject,Collect]ByCalling:" I'm
   happy to take suggestions on a replacement for "shallowCopy" if you
   can think of something better.

Here's a suggestion: do the reverse, so that you have a special name
for the one that doesn't work on a shallow copy:

	-selectInPlaceByCalling:
	-selectByCalling:

the [InPlace] doesn't do a copy.  This has the effect that whoever uses
a `InPlace' version will have to think about it before he does so.
Thus making it more safe.
   
   * "-species" method needed?

Take a look in the Smalltalk code and see where the `^self class'
definition in Collection is overridden.  This may give you a clue to
if it should be there.
   
   * What to return on errors?  We need to come up with better error,
   warning handling in general for Objective C.

I could easily supply a exception handling mechanism.  I think this is
a good idea, since it will often simplify a lot of code.  
   
   * Every method that has "Element" in the name also has a duplicate
   with "Object" in the name (with the types appropriately changed).
   This seems like a nice feature---help programmer by avoiding a lot of
   casting, and it gives our collection objects methods names familiar to
   NeXT programmers.  Would anyone prefer that they not be there?
   
That's fine.  Just let'em stay.

   * I've implemented LinkedLists based on Link objects.  This has the
   advantage that the user can nicely get at and manipulate the Links,
   however, it also means there is a fair amount of message passing for
   east addObject, removeObject, etc.  Anyone want to suggest a different
   implementation?   Perhaps something based on an array of structures
   that includes indeces of the next element.  This would prevent us from
   calling malloc in each insertion.  I'm happy to stick with using
   Link's unless someone want to convince me otherwise.
   
Add a kind of LinkedList that keeps objects that already under stand
the simple protocol:

	-nextLink	// return next Link
	-nextLink:	// addign next link

Plus perhaps accompanying -prevLink messages.  It is good to avoid
instance variable access, since this makes it far more general
(especially in connection with distributed objects)
   
   --------------------------------------------------------------------
   Changes I'd like in the Objective-C runtime:
   
   * Make objc_sizeof_type() public.

   * Add hash_node_for_key() to hash.h and hash.c.
   
   * How about removing cache as a parameter to the hashing functions in
   hash.h and hash.c.  Do the masking on the result of the hash function.
   This would seem much neater.
   
   * Add -shouldNotImplement to Object.
   
I agree on all points.  I'll add them right after the gcc 2.3 release.
RIght now I'm not allowed to add new features, or change anything that
isn't really needed.

/Kresten

From mccallum Fri Apr 30 11:29:48 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199304300016.AA07035@iesd.auc.dk>
Subject: Collection library again
CC: burchard@geom.umn.edu

Kresten Krab Thorup writes:
 >    * The protocol heirarchy has a nice, clean separation between the
 >    sequential collections with internally and externally specified
 >    orders.  We'd like this to show up in the implementation: i.e.
 >    Stack's, Queues, and SortedCollections should not conform to the
 >    OrdCollecting protocol (the one that allows insertion at arbitrary
 >    indeces).  Unfortunately, this causes a little pain in the
 >    implementation---for instance the SeqCollection(ForOrdColleting) and
 >    _BasicArray/Array stuff.  Any complaints or suggestions?
 >    
 > No complaints.  Just use "-shouldNotImplement:" and the mis-confomance
 > will turn out at once anyway.  This is a dynamic language right?  I'll
 > study the hierachies and see if I can make up something better.

When I ask [Queue conformsTo:@protocol(OrdCollecting)] I want to get
NO.  If Queue inherits from Array (which does conform to
OrdCollecting), my understanding is that I'll get YES, even if some of
the methods in Queue are overridden with "-shouldNotImplement:".

Here is a quote from NeXT's Concepts manual:  "A class is said to
conform to a formal protocol if it adopts the protocol or inherits
from a class that adopts it."

Hmm,.. I just tested this out with NeXT's cc and with our gcc.
Interesting.  NeXT's cc does as it says.  Our gcc does not.  The
source for my test program is at the end of this message.

NeXT's output:
Bar conforms to @protocol Foo 1
Bar2 conforms to @protocol Foo 1

Our gcc's output:
Bar conforms to @protocol Foo 1
Bar2 conforms to @protocol Foo 0

I think NeXT's defined behavior makes more sense.  Perhaps we should
change our gcc.  ...and this is why I need BasicArray and Array.  

It would be nice if the compile-time test for protocol conformance
checked the methods defined in superclasses also.

 >    * For names like "shallowCopy[Select,Reject,Collect]ByCalling:" I'm
 >    happy to take suggestions on a replacement for "shallowCopy" if you
 >    can think of something better.
 > 
 > Here's a suggestion: do the reverse, so that you have a special name
 > for the one that doesn't work on a shallow copy:
 > 
 > 	-selectInPlaceByCalling:
 > 	-selectByCalling:
 > 
 > the [InPlace] doesn't do a copy.  This has the effect that whoever uses
 > a `InPlace' version will have to think about it before he does so.
 > Thus making it more safe.

I agree that it would be nice to have both "copying" and "in place"
versions of these operations.  And perhaps I could be convinced that
the two names you mention are the best ones,... but I'm not convinced
yet.  I really think we need to make it obvious when reading code
which methods return new alloc'ed objects.  This is because:

   (1) Objective-C does not have garbage collection---the programmer
       has to keep track of new objects and free them when necessary.
   (2) We teach beginners that the default return value for
       methods is self.  Seeing the results of "-selectByCalling"
       getting freed does not imply the right thing.

 >    * "-species" method needed?
 > 
 > Take a look in the Smalltalk code and see where the `^self class'
 > definition in Collection is overridden.  This may give you a clue to
 > if it should be there.

It's overridden in MappedCollection (not in a way we need), Interval,
and Symbol.  In sum: I won't need it to implement the first base
Collection classes, but others may need it later.  I'll leave it in.

 >    * What to return on errors?  We need to come up with better error,
 >    warning handling in general for Objective C.
 > 
 > I could easily supply a exception handling mechanism.  I think this is
 > a good idea, since it will often simplify a lot of code.  

Could you send me this?  What I also really need is a mechanism for
optionally printing warnings that don't necessarily crash the program.

 >    * I've implemented LinkedLists based on Link objects.  This has the
 >    advantage that the user can nicely get at and manipulate the Links,
 >    however, it also means there is a fair amount of message passing for
 >    each addObject, removeObject, etc.  Anyone want to suggest a different
 >    implementation?   Perhaps something based on an array of structures
 >    that includes indeces of the next element.  This would prevent us from
 >    calling malloc in each insertion.  I'm happy to stick with using
 >    Link's unless someone want to convince me otherwise.
 >    
 > Add a kind of LinkedList that keeps objects that already under stand
 > the simple protocol:
 > 
 > 	-nextLink	// return next Link
 > 	-nextLink:	// addign next link
 > 
 > Plus perhaps accompanying -prevLink messages.  

When using the LinkedList collection is would be nice to be able to
both 
    (1) add arbitrary elements to the collection, just as with all the
        other collections.  (i.e. [llist addElement:"bird"]; or 
        [llist addObject:foo]; where foo is not a Link.)
    (2) and manipulate the Links themselves. 
        (i.e. [llist2 insertLink:[llist removeLinkAt:1] at:4]; )

My implementation provides this.  Needless to say, it can't provide
this by insisting on being a collection of objects that conform to the
Link protocol.

 > It is good to avoid
 > instance variable access, since this makes it far more general
 > (especially in connection with distributed objects)

Hmm... I actually did some (admittedly yucky) direct reading (but not
writing) of instance variables in my implementation.  Without this the
amount of message passing gets really ridiculous.  But if we think
that people will actually use LinkedList's in which the Link objects
are remote (wow!), I suppose I will have to change this.  Right now I
can't imagine people doing this.  What I can imagine is people using a
LinkedList whose elements are remote objects.  My current
implementation handles this nicely.

I'm going to go ahead and remove the underscores from the abstract
class names, as well as taking some of your other suggestions.

Thanks,
	Andrew

--------------- 8< -------------
#include <objc/Object.h>
#include <stdio.h>

@protocol Foo
- foo;
@end

@interface Bar : Object <Foo>
- cow;
@end

@implementation Bar
- cow
{
  printf("cow\n");
}
- foo
{
  printf("foo\n");
}
@end

@interface Bar2 : Bar
//- foo;
@end

@implementation Bar2
/*
- foo
{
  return [self notImplemented:_cmd];
}
*/
@end

main()
{
  printf("Bar conforms to @protocol Foo %d\n", 
	 (int)[Bar conformsTo:@protocol(Foo)]);

  printf("Bar2 conforms to @protocol Foo %d\n", 
	 (int)[Bar2 conformsTo:@protocol(Foo)]);
}
--------------- 8< -------------

From burchard@geom.umn.edu Fri Apr 30 00:04:02 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16734; Fri, 30 Apr 93 00:03:59 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/x) id AA24017; Fri, 30 Apr 93 00:03:56 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Thu, 29 Apr 1993 23:03:54 -0500
Message-Id: <9304300403.AA24769@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Thu, 29 Apr 93 23:03:52 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: burchard@geom.umn.edu
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: mccallum@cs.rochester.edu
Subject: Re: Collection library again
Date: Thu, 29 Apr 93 23:03:52 -0500

I like all of Kresten's comments (especially about not using  
underscores, and the "InPlace" stuff).

And I also encourage you go ahead and post your preliminary design to  
gnu-objc....I've gotten a lot of really good feedback there.

PB

From burchard@geom.umn.edu Mon May  3 23:36:01 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA12457; Mon, 3 May 93 23:35:57 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/x) id AA08896; Mon, 3 May 93 23:35:54 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Mon, 3 May 1993 22:35:47 -0500
Message-Id: <9305040335.AA00445@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Mon, 3 May 93 22:35:52 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: burchard@geom.umn.edu
To: mccallum@cs.rochester.edu
Cc: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Collections, ownership, and the copy protocol
Date: Mon, 3 May 93 22:35:52 -0500

I started looking over libcoll-930429, and the overall design looks  
good.  If the idea of combining all element types in one  
implementation works out, it would really be quite a relief for the  
end-user.

What I think needs some more thought is ownership of contained  
objects (which I think we discussed a bit before).  There is also  
apparently some confusion about the purpose of -deepen.

An example that begins to expose these issues is the incompatibility  
of your List class with NeXT's.  The latter treats -copy as if it  
were -shallowCopy.  That's because NeXT's List assumes it doesn't own  
the elements---except during archiving...argggh.

Your collection classes also don't yet deal clearly with the  
ownership issue, which becomes much more important in the absence of  
garbage collection.  If your Lists don't own their elements, what  
happens when we -copy (now meaning deep copy) one of your Lists and  
new objects are created at the copy's behest and hidden inside of it?   
After a few collection manipulations it could be impossible to avoid  
losing track of memory.

The copy protocol is a good place to further dig into these issues.   
To start with a specific problem, note that -copy already contains  
-deepen; [copy] is by default equivalent to [[shallowCopy] deepen].   
So the following is at least a memory leak:

HashTable.m:193
>             node->value = [(id)(node->value) copy];
>             [(id)(node->value) deepen];

Part of reason for -deepen was to avoid direct access to another  
object's ivars in -copy.  However, you are still using this practice  
in -shallowCopy itself, because even shallow copies (in your  
interpretation) have to be deepened a bit.  Given your semantics, you  
can do this more cleanly by making the base class [shallowCopy] be  
[[super shallowCopy] fillShallow], and then overriding only  
-fillShallow in subclasses.

However, the way I probably would have organized this is to keep  
-shallowCopy as the raw runtime operation (similar to -alloc).  In  
addition to copying the array of element pointers, -deepen would copy  
only those elements in the array which the collection owns.  In this  
way, the end-user method, -copy, would be appropriately deep or  
shallow, depending on element ownership.

I'm not sure it makes sense to have an explicit choice of shallow and  
deep copies, because this seems to simply be an indirect way of  
telling the collection whether the objects are "internal" or  
"external" to the collection.  Well, maybe we should just go ahead  
and tell the collection about this ownership issue directly,  
especially since the collection needs to know this for all sorts of  
operations other than copying (-free, -read:, -write:, remote  
messaging, etc).

This doesn't have to burden the user much since the overwhelming  
majority of the time, collections are used to group and manage  
"external" objects.  The "external" case can be the default, which  
requires no special intervention by the user.

What are your thoughts on these issues?

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

From mccallum Fri May  7 13:44:50 1993 EDT
To: burchard@geom.umn.edu
In-reply-to: <9305070108.AA01882@mobius.geom.umn.edu>
Subject: Re: Collections, ownership, and the copy protocol
Cc: Kresten Krab Thorup <krab@iesd.auc.dk>

Hi Paul,

You've convinced me of the benefit of -deepen, but I haven't quite
understood some of your other points.

burchard@geom.umn.edu writes:
 > > * Shallow copying: We should make it *impossible* to end
 > > up with a collection that contains only a copy of the ivars
 > > (i.e. I don't think I should not leave "-shallowCopy" as
 > > it is).  The users can royally screw themselves with this behavior.
 > 
 > The point of these methods is to provide a consistent protocol for  
 > extending the end-user copying method, -copy.  Just as you extend  
 > +new by overriding -init, you extend -copy by overriding -deepen.  

Yup, I agree.  I see the similarities between "new/alloc/init" and
"copy/shallowCopy/deepen".  

 > Such a protocol is beneficial because both +new and -copy are sent to  
 > objects other than the one which must eventually initialize itself.   
 > Both -init and -deepen exist in order to eliminate the need---and  
 > temptation---to directly access another object's ivars (as you do in  
 > libcoll).

Which ivar access are you referring to here?  Something related to
copying, or are you talking about Link objects?  Is this a suggestion
to use @protocol's for links instead of the current setup?

 > I'd favor having a single -copy method and letting the collection  
 > object keep track of which objects are external and internal.  That's  
 > just one vote, of course---let the gnu-objc crowd in on these issues.

OK, I'd like the make sure I understand how the ownership semantics
might work.  Is this what you have in mind?:

Add "-setOwner:(BOOL)flag" and "-(BOOL)owner" to the <Collecting>
protocol.  Using an instance variable, a collection object keeps track
of whether or not it owns all its contents.  If a collection is the
owner, then: 1) it sends "-free" to its content objects when the
collection is free'd, 2) it writes the object (instead of
writeReference) when the collection is written, 3) it sends an
effective [[ shallowCopy] deepen] to each of the contents when
responding to "-copy".

Any time we keep track of ownership, I don't understand how we will
avoid the all-too-easily-reachable situation in which two different
collection objects think they own the same object (resulting in errors
when the collections are free'd).

fooObject = [[Foo alloc] init];
coll1 = [[[Array alloc] init] setOwner:YES];
coll2 = [[[Array alloc] init] setOwner:YES];
[coll1 addObject:fooObject];
[coll2 addObject:fooObject];

It seems that what we really need here is reference counting.  I could
add a reference counting protocol to the collections, but there would
still be easy, natural ways of getting around it.  ** What we really
need is real garbage collection. ** But I don't think we're going to
get it, and I'm not sure we would really want it's overhead.

There is an important difference between "new/alloc/init" and
"copy/shallowCopy/deepen".  With "new" there is no ambiguity about
what the programmer wants.  With "copy" it is possible that the
programmer could want two different things: 1) a deep copy completely
independent of the original, 2) a new collection of pointers to the
old objects.  There is nothing inherent in the original collection
itself that would indicate which of these options that programmer
wanted---the choice depends on the situation, what the programmer
intends to do with the resulting copy.

' looking forward to your feedback,
	Andrew

From mccallum Fri May  7 16:18:44 1993 EDT
To: burchard@geom.umn.edu
CC: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <9305071933.AA02648@mobius.geom.umn.edu>
Subject: Re: Collections, ownership, and the copy protocol

burchard@geom.umn.edu writes:
 > I would love to see an *optional* garbage collector in libobjc.
 > 
 > But I think GC should be optional for libcoll, because most of the  
 > time, collection objects will be used as lightweight ways to organize  
 > external objects.  This most important task should not be hindered by  
 > the "threat" of GC.

Ditto.

- Andrew

P.S.  I'm thinking about merging the two sequenceable collection
protocols into one.  (i.e. not distinguishing between the protocol
that lets you access and remove objects by index, and the protocol
that does the above and also lets you insert objects at arbitrary
indices.)  It's a meaningful distinction, but it's starting to look
like it's not worth the mess it causes.  This means that objects
conforming to SortedCollecting would have to override insertObject:at:,
etc, with "-shouldNotImplement".  (It would be nice to set up some 
automatic way for objects to respond properly to "-respondsTo:" for
these methods.)  Opinions on the merge?

I'm also thinking about modifying the method names in <KeyedCollecting>
a bit, and making my <IndexedCollecting> inherit from
<KeyedCollecting>, in essence recognizing that IndexedCollection's
are also keyed---by unsigned integers.  This scheme makes things like
a MappedCollection ala Smalltalk particularly clean.  Opinions?

P.P.S.  I'm off for the weekend.  Talk to you all again on Monday.


From burchard@geom.umn.edu Fri May  7 11:21:59 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA01701; Fri, 7 May 93 11:21:55 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/x) id AA25566; Fri, 7 May 93 11:24:01 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Thu, 6 May 1993 20:08:05 -0500
Message-Id: <9305070108.AA01882@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Thu, 6 May 93 20:08:04 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: burchard@geom.umn.edu
To: mccallum@cs.rochester.edu
Cc: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Re: Collections, ownership, and the copy protocol
Date: Thu, 6 May 93 20:08:04 -0500

> * Shallow copying: We should make it *impossible* to end
> up with a collection that contains only a copy of the ivars
> (i.e. I don't think I should not leave "-shallowCopy" as
> it is).  The users can royally screw themselves with this behavior.

The point of these methods is to provide a consistent protocol for  
extending the end-user copying method, -copy.  Just as you extend  
+new by overriding -init, you extend -copy by overriding -deepen.  


Such a protocol is beneficial because both +new and -copy are sent to  
objects other than the one which must eventually initialize itself.   
Both -init and -deepen exist in order to eliminate the need---and  
temptation---to directly access another object's ivars (as you do in  
libcoll).

I'd favor having a single -copy method and letting the collection  
object keep track of which objects are external and internal.  That's  
just one vote, of course---let the gnu-objc crowd in on these issues.

PB

From mccallum Wed May 19 16:38:20 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: libcoll almost ready for first public showing

Hi Kresten,

I've been working away on some significant improvements to libcoll,
and soon I'd like to announce it in gnu-objc.  

In order to keep everything together I'd like to make it available at
your ftp site (iesd.auc.dk).  Will that be OK?  Do I have permission
to put things there now?


Just to fill you in on some of the biggest changes:

* got rid of OrderedCollecting / SequencedCollecting distinction,
which was bogus anyway.  Using your suggestion, I called the protocol
for ordered collections "IndexedCollecting"

* I added a "KeyedCollecting" protocol that recognizes the
similarities between all collections containing elements accessible by
a key.

* I completely rewrote the LinkedList implementation.  Removed the
instance variable access, defined a <ListLinking> protocol and created
a LinkList class, as you did in your preliminary libcoll.

* ..and of course, many bug fixes

* (I haven't dealt with archiving or ownership issues yet).

-- Andrew

P.S. When can I get your OO stream implementation?  Will it have a
"printOn:" convention also?



From krab@iesd.auc.dk Wed May 19 18:49:36 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA23313; Wed, 19 May 93 18:49:33 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA21995; Wed, 19 May 93 18:49:31 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA28299
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Thu, 20 May 1993 00:49:13 +0200
Received: by xiv.iesd.auc.dk id AA14316
  (5.65c8/IDA-CLIENT/MD); Thu, 20 May 1993 00:49:21 +0200
Message-Id: <199305192249.AA14316@xiv.iesd.auc.dk>
In-Reply-To: <9305192038.AA28474@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: libcoll almost ready for first public showing
Date: Thu, 20 May 1993 00:49:21 +0200


  I've been working away on some significant improvements to libcoll,
  and soon I'd like to announce it in gnu-objc.  

I'm absolutely excited!  Can I have a copy and just look around?
  
  In order to keep everything together I'd like to make it available at
  your ftp site (iesd.auc.dk).  Will that be OK?  Do I have permission
  to put things there now?
  
Sure.  I'll setup an accountfor you when I get to the office first
thing tomorrow morning.
  
  * got rid of OrderedCollecting / SequencedCollecting distinction,
  which was bogus anyway.  Using your suggestion, I called the protocol
  for ordered collections "IndexedCollecting"

Fine.
  
  * I added a "KeyedCollecting" protocol that recognizes the
  similarities between all collections containing elements accessible by
  a key.

I'm looking forward to se how you handle all these different kinds of
arguments... 
  
  * I completely rewrote the LinkedList implementation.  Removed the
  instance variable access, defined a <ListLinking> protocol and created
  a LinkList class, as you did in your preliminary libcoll.

This is really the old time/space tradeoff.  Would you like "link"
objects hanging around or not.  In my first implementation I had both,
perhaps that would be worth considering.
  
  * (I haven't dealt with archiving or ownership issues yet).

  P.S. When can I get your OO stream implementation?  Will it have a
  "printOn:" convention also?

As of now I've not done anything fancy at low level streams.  I've
made various things around streams, such as the
Binary{Encoder,Decoder} (Together implementing the encoding level of
typed streams) classes whose instances are connected to something
conforming to <ByteStream> (providing writeBytes and readBytes).
Besides this I've made some INET/Socket classes.  I've not gone very
far, most of it is rather primitive right now.

I think the design of the streams library should be based on a
cooperation between to kinds of "streams":  Stream providers and
Stream filters.  Thus, I'll not have a "FileStream" on which you can
do a "printf", but seperate formatters and providers.  The encoders
are examples of filters.

My current plans look like this (*==implemented):

UnixStream	   * anything that has a file descriptor <ByteStream>
  FileStream       * a seekable named file <SeekableStream>
  PipeStream       * unixish piped streams (non-seekable)
    SocketStream   * streamed (tcp/SOCK_STREAM) sockets
      INETSocket   * sockets connected to ports on hosts (AF_INET)
      UNIXSocket   - UNIX domain sockets (AF_UNIX)
    NamedPipe      - UNIX named pipes
    UnnamedPipe    - things that come from socketpair()
MemoryStream       - in-memory bytestream <ByteStream>
  MemoryFile       - looks like a file <SeekableStream>
  MemoryPipe       - byte oriented pipe, manages indep. read/write pointers

StreamFilter       * has initializers for common Streams like files
  TypedStream      * guess what! <Encoding,Decoding>
  AsciiFiler       - Same as TypedStream <Encoding,Decoding>
  StdFilter        - printf, scanf etc...

Since filters will often have distinct input and output streams
"below" these are kept in distinct ivars even though they may be
equal.  

All of the streams are only "bytestreams".  Filters are more like
interpreters or small "compilers" which perform transformations.
Please let me know if you have any comments, extensions, questions
regarding this.  

Until july 1st I'll be *very* buzy doing my exams, so I'll not be able
to do anything but discussions until then.

/Kresten

BTW:  My University has just offered me 10h/week payed for doing
FSF/GNU stuff (~$15/h).  Sure I'll accept (I'm doing it anyway) but
isn't it just great?  This should be considered a contribution to FSF
since we cannot transfer funds directly.

From mccallum Thu May 20 11:49:03 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305192249.AA14316@xiv.iesd.auc.dk>
CC: Paul Burchard <burchard@horizon.gw.umn.edu>
Subject: Re: libcoll almost ready for first public showing

Hi Kresten,

You said you wanted to have an early peek at libcoll...

Take a look at cs.rochester.edu:pub/libcoll-930520.tar.z.  Beginning
by looking at the README is a better idea than it was before since
it's a little more coherent now.

Could I also get an early peek at your Stream library?

Enjoy,
	Andrew


From krab@iesd.auc.dk Thu May 20 17:20:36 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA28366; Thu, 20 May 93 17:20:33 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA26452; Thu, 20 May 93 17:20:30 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA10233
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Thu, 20 May 1993 23:18:01 +0200
Received: by xiv.iesd.auc.dk id AA22999
  (5.65c8/IDA-CLIENT/MD); Thu, 20 May 1993 23:18:10 +0200
Message-Id: <199305202118.AA22999@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk, burchard@geom.umn.edu
Subject: Collection of comments :-)
Date: Thu, 20 May 1993 23:18:10 +0200


In general it look absolutely fabulous!  I have some random comments
from just reading the source.

Any method that causes elements to be removed from a collection should
return that element if possible.  This is generally so, but Delegate
does not conform to this.  

How about letting ElementListLink not inherit object, but then
delegate to the content object?

Since we have this implicit cast to elt, all ..Object methods are
implemented as wrappers for ..Element methods.  This wil not encurage
anyone to use those since it costs an extra method call :-)

I think it should be ok to have nil objects in collections.  The
missing element and non-exsisting indiced should be ~0 i.e. one with
all bits set.  This is much less likely to cause conflict than 0.

`withElements...:whileTrue: ' is a great invention.  Encurage people
to use this instead of nasty goto hacks that may cause trouble for
internal cleanup.

Implement a generic qsort, which takes an array-accesor function
(elem*(*)(void* array, int index) as extra argument.  Using this you
can use the same qsort for all kinds of indexed collections.

printForDebugger may be obviated by a special DebuggerStreamFilter
allowing the debugger to use `encodeTo:' or the like...

Did you try the exception handling?  It will not make it even to
2.4.1, but I think I'll distribute an extended runtime shortly so you
shouldnt care if it's not in right now. 

I have to decide on the +initialize stuff.  Please convince me to
something!

Neat that you use OBJC_FREE/OBJC_MALLOC this allows for alternative
mechanisms to be installed (such as gc).  I'll put them in the runtime
headerfiles and use them when I get time.  Please remind me or send me
a patch....  Why not add: OBJC_CMALLOC -- cleaes content. OBJC_AMALLOC
allocate memory that will not contain pointers `atomic' for future gc!

-[Dictionary addObject] may do something reasonable if the argument
conforms to the <Associating> protocol :-) i.e. answering to -key and
-value etc.

KeyedCollection's should decide how to handle -makeElementsPerform and
friends.  I think it should simply iterate on the values.

If -conformsTo: is gonna be heavily used, I could make the runtime
keep a real hash table in stead of the current linear table.

Someone build a preprocessor allowing one to "inherit" documentation
for methods!

Set: Should intersectWith:, unionWith:, differenceWith: not come in
shallowCopy versions as well?

Why not make Stack a subclass of ordinary Arrays?  Why use
CircularArray, which has more overhead?

Why does the system depend on the assertion in +[Collection initialize]?

The hashing needs an update.  You're welcome to send me patches.

It is absolutely GREAT!  Congratulations!

/Kresten


From krab@iesd.auc.dk Thu May 20 17:34:46 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA28473; Thu, 20 May 93 17:34:43 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA26555; Thu, 20 May 93 17:34:42 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA10404
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Thu, 20 May 1993 23:34:22 +0200
Received: by xiv.iesd.auc.dk id AA23084
  (5.65c8/IDA-CLIENT/MD); Thu, 20 May 1993 23:34:31 +0200
Message-Id: <199305202134.AA23084@xiv.iesd.auc.dk>
In-Reply-To: <199305202118.AA22999@xiv.iesd.auc.dk> "krab@iesd.auc.dk"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk, burchard@geom.umn.edu
Subject: Filenames and other names
Date: Thu, 20 May 1993 23:34:31 +0200

Filenames should be reduced to 14 chars. I suggest `Collection' is
shortened to `Cltn' -- but only for file names.

Some time in the future, RMS will allow me to put what is now
`libobjc.a' into `libgcc.a'.  This will release libobjc.a to contain
stuff like the collectio stuff here and my streams plus other generic
stuff.  For now, we should perhaps make up a good name for this
library, perhaps `libobjective.a' that's 14 chars...

/Kresten

Talking of filenames:  Smalltalk has a neat subclass of string for
filenames.  This one contains generic path name manipulation, so that
this may be hidden if used on another OS.

From mccallum Fri May 21 11:39:03 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
CC: burchard@geom.umn.edu
In-reply-to: <199305202118.AA22999@xiv.iesd.auc.dk>
Subject: Collection of comments :-)

Hello, friends,

Kresten Krab Thorup writes:
 > In general it look absolutely fabulous!  I have some random comments
 > from just reading the source.
Good!  I'm glad you like it.

 > Any method that causes elements to be removed from a collection should
 > return that element if possible.  This is generally so, but Delegate
 > does not conform to this.  

I assume you mean DelegateList?  I just changed
-delegateListRemoveObject to return the object.  Is this what you mean?

 > How about letting ElementListLink not inherit object, but then
 > delegate to the content object?

Interesting idea.  So then ElementListLink wouldn't inherit from
ListLink (because I think that ListLink should inherit from Object,
don't you?).  This is fine.  What should we do if the contents of the
LinkedList are not Object's, though?  Perhaps we should have both
ElementListLink and ObjectListLink, and I could implement
ObjectListLink with your suggestion.  Tell me if you think this is a
good idea, and I'll do it.

 > Since we have this implicit cast to elt, all ..Object methods are
 > implemented as wrappers for ..Element methods.  This wil not encurage
 > anyone to use those since it costs an extra method call :-)

Yeah, I know... sigh.  So I figure that the programmers who care will
go through the extra trouble to use the ...Element calls, and everyone
else will have pretty method names.  Do you have any other solutions?
Reimplementing all the ..Object methods not only seems like a major
pain, but also does nasty things to inheritance and overriding.

 > I think it should be ok to have nil objects in collections.  The
 > missing element and non-exsisting indiced should be ~0 i.e. one with
 > all bits set.  This is much less likely to cause conflict than 0.

OK, I can do this.  What is the best way to get ~0?  Using
0xffffffff doesn't seem very portable.  Is UINT_MAX what we want; will
it do the right thing on 64-bit machines?

 > `withElements...:whileTrue: ' is a great invention.  Encurage people
 > to use this instead of nasty goto hacks that may cause trouble for
 > internal cleanup.

Yup, I rather like it myself also.

 > Implement a generic qsort, which takes an array-accesor function
 > (elem*(*)(void* array, int index) as extra argument.  Using this you
 > can use the same qsort for all kinds of indexed collections.

I agree that implementing qsort for use will all Array-based
IndexedCollection's is a good idea?  Buy why use this array-accessor
function---why not [.. elementAtIndex:] ?

 > printForDebugger may be obviated by a special DebuggerStreamFilter
 > allowing the debugger to use `encodeTo:' or the like...

Good, this is just what I want.  For now, I've already generalized
printForDebugger to correctly print all different kinds of contents:
int's, float's, SEL's, etc.

 > Did you try the exception handling?  It will not make it even to
 > 2.4.1, but I think I'll distribute an extended runtime shortly so you
 > shouldnt care if it's not in right now. 

Well, I'm not sure calling EX_RAISE() when an index is out of bounds
is what the user would what?  What do you think?

 > I have to decide on the +initialize stuff.  Please convince me to
 > something!

I agree strongly with Paul Burchard.  ** Keep the NeXT semantics. **

 > Neat that you use OBJC_FREE/OBJC_MALLOC this allows for alternative
 > mechanisms to be installed (such as gc).  I'll put them in the runtime
 > headerfiles and use them when I get time.  Please remind me or send me
 > a patch....  Why not add: OBJC_CMALLOC -- cleaes content. OBJC_AMALLOC
 > allocate memory that will not contain pointers `atomic' for future gc!

Yup, in fact the new definitions of OBJC_MALLOC, etc. dereference a
function pointer, so switching to GC should be a breeze.  This is not
something that is particular to libcoll,  you should take a look at
it and decide if you want to do it a different way or not.

 > -[Dictionary addObject] may do something reasonable if the argument
 > conforms to the <Associating> protocol :-) i.e. answering to -key and
 > -value etc.

I could pull the -key and -value from an <Associating> object and
insert them into the Dictionary, but the Dictionary would not keep the
<Associating> object itself.  We might get in trouble if the user
expected the Dictionary to keep track of the original <Associating>
object.  I'm really not sure what to do here.  For now I'll nothing,
but I'm open to more suggestions, or just convincing that this above
behavior is fine.

 > KeyedCollection's should decide how to handle -makeElementsPerform and
 > friends.  I think it should simply iterate on the values.

They already do, just by inheritance.  In KeyedCollections
-withElementsCall: passes all the "values" to the function.

 > If -conformsTo: is gonna be heavily used, I could make the runtime
 > keep a real hash table in stead of the current linear table.

My feeling on this is, "wait and see" if -conformsTo: turns out to be
a performance bottleneck.

 > Someone build a preprocessor allowing one to "inherit" documentation
 > for methods!

I would be nice to come up with a machine extractable format for
putting documentation in the source code.

 > Set: Should intersectWith:, unionWith:, differenceWith: not come in
 > shallowCopy versions as well?

OK, I can add those.

 > Why not make Stack a subclass of ordinary Arrays?  Why use
 > CircularArray, which has more overhead?

You're absolutely right.  CircularArray makes sense for Queue's, but
not Stacks.  I'll change it.

 > Why does the system depend on the assertion in +[Collection initialize]?

sizeof(elt) must == sizeof(void*) because the compare and hash
functions used by hash.c take void* arguments, and the entire elt
needs to get into the compare and hash functions.  I'm a bit
uncomfortable with these casts.  What if we rewrote hash.c to use
elt's!  I bit scary,.. but it certainly would make libcoll's
implementation cleaner.

Hmm, I'm trying to remember why I thought it was so important that
sizeof(id) == sizeof(elt)... I guess sizeof(id) will always ==
sizeof(void*) anyway, n'est-ce pas?

 > The hashing needs an update.  You're welcome to send me patches.

Let me know what you think we should do about the idea above (re. elt
data type used in libcoll and void* used in hash.c).

 > It is absolutely GREAT!  Congratulations!

It feels good to get positive feedback.  I'm glad you like it.
' looking forward to your reponse on this note.

- Andrew


From mccallum Fri May 21 11:44:47 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
CC: burchard@geom.umn.edu
In-reply-to: <199305202134.AA23084@xiv.iesd.auc.dk>
Subject: Filenames and other names

Kresten Krab Thorup writes:
 > Filenames should be reduced to 14 chars. I suggest `Collection' is
 > shortened to `Cltn' -- but only for file names.

Oh *Yuck*!  I dislike the idea of changing the classnames to use
"Cltn", but I *really* dislike the idea of having filenames different
from class names.  ....I can't get over how disgusting I think it is
that we have to keep filenames to 14 chars.  ...do we really have to?
:-(

 > Talking of filenames:  Smalltalk has a neat subclass of string for
 > filenames.  This one contains generic path name manipulation, so that
 > this may be hidden if used on another OS.

I'm not sure I understand.  Are you saying there may be a way for me
to keep my nice, unabreviated class names?

-- Andrew


From mccallum Fri May 21 11:52:22 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305211257.AA18951@iesd.auc.dk>
Subject: shallowCopyReplaceFrom:to:with:

Hello again,

Kresten Krab Thorup writes:
 > Here is an implementation that works for all `IndexedCollection's

I think the current implementation of shallowCopyReplaceFrom:to:with:
in IndexedCollection also works for all IndexedCollection's, BUT I do
notice that your implementation does have different semantics.

To me, the phrase "replace from x to y with" implies that the space
vacated by the elements from x to y would be filled with all the
elements of replaceCollection, even if replaceCollection were smaller
or larger than the gap from x to y.

How about adding this method with the name
	shallowCopyReplaceFrom:to:using:
which suggests to me the semantics of your implementation.
I'm open to your suggestions on this.

 > - shallowCopyReplaceFrom: (unsigned)start to: (unsigned)stop 
 >     with: (id <Collecting>)replaceCollection
 > {
 >   id newColl = [self shallowCopy];
 >   unsigned index = start;
 >   BOOL continue = YES;
 >   void doIt (elt e)
 >     {
 >       [newColl replaceElementAtIndex: index with: e];
 >       continue = (index++ != stop);
 >     }
 >   [replaceCollection withElementsCall: doIt whileTrue: &continue];
 >   return newColl;
 > }

-- Andrew


From mccallum Fri May 21 11:53:57 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305211438.AA20257@iesd.auc.dk>
Subject: GapArray + Storage implemented

Great!  Thank you!  I've already put them in with the others.

Andrew



From krab@iesd.auc.dk Fri May 21 11:04:11 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA01680; Fri, 21 May 93 11:04:09 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA29329; Fri, 21 May 93 11:04:08 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA20508
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Fri, 21 May 1993 17:03:46 +0200
Message-Id: <199305211503.AA20508@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA17500; Fri, 21 May 93 17:04:13 +0200
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: Portability hints
Date: Fri, 21 May 1993 17:03:46 +0200

This is just a bunch of hint on hwo to make your code more portable.

Don't include any system header files if it can be avoided.  Even
stdlib.h is not available on all systems.  

sizeof(long) == sizeof(int) should not be relied upon.  On most 64
bits machines, int is 32 bit and long is 64.

Use `0' instead of NULL.  0 is a valid pointer of any kind, and you
mey get trouble from headerfiles if you need NULL.

GNU style:

Use (*fptr)(args) syntax when calling a function via a pointer.  This
is part of the GNU coding standards, and besides it makes it more
explicit that it actually is a function pointer.


From mccallum Fri May 21 11:55:17 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305211503.AA20508@iesd.auc.dk>
Subject: Portability hints

Thanks, for the good suggestions.  I agree with all of them.  I'll
make the appropriate changes.

- Andrew


From mccallum Fri May 21 13:00:50 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
CC: burchard@geom.umn.edu
Subject: String classes

We should think about the possibility of a String class that conforms
to <IndexedCollecting>.  I think it could work... I'm not sure I'm up
to volunteering to do it right now, though.

We should also take a look at NeXT's String heirarchy.  I've got *.h
files that I distilled from poking around the NeXT's library.  I could
give them to anyone who is interested.  Eventually we're going to want
to duplicate NeXT's 
		@"a new constant string object" 
functionality in GNU Objective-C.

...Hmmm, I wonder if NeXT would donate their String classes :-)

-- Andrew


From krab@iesd.auc.dk Fri May 21 14:56:56 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA02962; Fri, 21 May 93 14:56:53 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA00554; Fri, 21 May 93 14:56:52 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA22831
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Fri, 21 May 1993 20:56:28 +0200
Message-Id: <199305211856.AA22831@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA18695; Fri, 21 May 93 20:56:56 +0200
In-Reply-To: <9305211552.AA07771@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: shallowCopyReplaceFrom:to:with:
Date: Fri, 21 May 1993 20:56:28 +0200

  To me, the phrase "replace from x to y with" implies that the space
  vacated by the elements from x to y would be filled with all the
  elements of replaceCollection, even if replaceCollection were smaller
  or larger than the gap from x to y.

I just realize that what you describe is the semanthics of `splice' in
perl.  An excerpt from the online docs:

     splice(ARRAY,OFFSET,LENGTH,LIST)
     splice(ARRAY,OFFSET,LENGTH)
     splice(ARRAY,OFFSET)
             Removes the elements designated by OFFSET and LENGTH
             from  an  array, and replaces them with the elements
             of LIST, if any.  Returns the elements removed  from
             the array.  The array grows or shrinks as necessary.
             If LENGTH is omitted, removes everything from OFFSET
             onward.   

Why not use this semanthics, which is very close to what you
suggested.  Forget about what I suggested in my last letter.

/Kresten

From krab@iesd.auc.dk Fri May 21 15:00:52 1993
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA03015; Fri, 21 May 93 15:00:49 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA00574; Fri, 21 May 93 15:00:48 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA22867
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Fri, 21 May 1993 21:00:25 +0200
Message-Id: <199305211900.AA22867@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA18715; Fri, 21 May 93 21:00:52 +0200
In-Reply-To: <9305211544.AA07693@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu
Cc: krab@iesd.auc.dk
Subject: Filenames and other names
Date: Fri, 21 May 1993 21:00:25 +0200

  Kresten Krab Thorup writes:
   > Filenames should be reduced to 14 chars. I suggest `Collection' is
   > shortened to `Cltn' -- but only for file names.
  
  Oh *Yuck*!  I dislike the idea of changing the classnames to use
  "Cltn", but I *really* dislike the idea of having filenames different
  from class names.  ....I can't get over how disgusting I think it is
  that we have to keep filenames to 14 chars.  ...do we really have to?
  :-(
  
It is not because I like it, but I really think so.  Consider it as a
standard you'll have to swallow -- it will make the life so much
easier for a lot of people.

One could argue that the class names should be the same as file names,
but I don't like the idea of abbreviating the class names either.

/Kresten

From krab@iesd.auc.dk Fri May 21 15:28:45 1993
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA03233; Fri, 21 May 93 15:28:42 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA00724; Fri, 21 May 93 15:28:38 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA23141
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Fri, 21 May 1993 21:28:14 +0200
Message-Id: <199305211928.AA23141@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA18862; Fri, 21 May 93 21:28:42 +0200
In-Reply-To: <9305211539.AA07630@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu
Subject: Collection of comments :-)
Date: Fri, 21 May 1993 21:28:14 +0200

   > Any method that causes elements to be removed from a collection should
   > return that element if possible.  This is generally so, but Delegate
   > does not conform to this.  
  
  I assume you mean DelegateList?  I just changed
  -delegateListRemoveObject to return the object.  Is this what you mean?

Yup.
  
   > How about letting ElementListLink not inherit object, but then
   > delegate to the content object?
  
  Interesting idea.  So then ElementListLink wouldn't inherit from
  ListLink (because I think that ListLink should inherit from Object,
  don't you?).  This is fine.  What should we do if the contents of the
  LinkedList are not Object's, though?  Perhaps we should have both
  ElementListLink and ObjectListLink, and I could implement
  ObjectListLink with your suggestion.  Tell me if you think this is a
  good idea, and I'll do it.
  
What you describe sounds fine.  

   > Since we have this implicit cast to elt, all ..Object methods are
   > implemented as wrappers for ..Element methods.  This wil not encurage
   > anyone to use those since it costs an extra method call :-)
  
  Yeah, I know... sigh.  So I figure that the programmers who care will
  go through the extra trouble to use the ...Element calls, and everyone
  else will have pretty method names.  Do you have any other solutions?
  Reimplementing all the ..Object methods not only seems like a major
  pain, but also does nasty things to inheritance and overriding.

You're right.  It was only an observation.  

   > I think it should be ok to have nil objects in collections.  The
   > missing element and non-exsisting indiced should be ~0 i.e. one with
   > all bits set.  This is much less likely to cause conflict than 0.
  
  OK, I can do this.  What is the best way to get ~0?  Using
  0xffffffff doesn't seem very portable.  Is UINT_MAX what we want; will
  it do the right thing on 64-bit machines?
  
I believe  ~0L  is the best way to do it.  Since it only has to be
computed once you could make a special global instance of elt which is
properly initialized... 

   > Implement a generic qsort, which takes an array-accesor function
   > (elem*(*)(void* array, int index) as extra argument.  Using this you
   > can use the same qsort for all kinds of indexed collections.
  
  I agree that implementing qsort for use will all Array-based
  IndexedCollection's is a good idea?  Buy why use this array-accessor
  function---why not [.. elementAtIndex:] ?

Yes, why not simply implement quicksort as a method of
IndexedCollection.  He'res an implementation from the Sather library
somewhere to make life easier for you.

   quicksortL(l:INT;r:INT) is
      -- quicksort the array from start to finish 
      i:INT := l; j:INT := r; x:INT; w:INT;
      x := sortlist[(l + r) / 2 ];
      loop 
         until sortlist[i] >= x loop
               i := i + 1;
         end;
         until x >= sortlist[j] loop
              j := j - 1;
         end;
         if i <= j then
            w := sortlist[i];
            sortlist[i] := sortlist[j];
            sortlist[j] := w;
            i := i + 1;
            j := j - 1;
         end;
         if i > j then
            break;
         end;
      end;
      
      if l < j then
         quicksortL(l,j);
      end;
      if i < r then
         quicksortL(i,r);
      end;
   end; -- quicksortL

  
   > Did you try the exception handling?  It will not make it even to
   > 2.4.1, but I think I'll distribute an extended runtime shortly so you
   > shouldnt care if it's not in right now. 
  
  Well, I'm not sure calling EX_RAISE() when an index is out of bounds
  is what the user would what?  What do you think?

Index out of bounds is a fine condition for an exception.  
  
   > I have to decide on the +initialize stuff.  Please convince me to
   > something!
  
  I agree strongly with Paul Burchard.  ** Keep the NeXT semantics. **
  
Ok, I'll change it as soon as 2.4.1 is released.  I will see if rms
accepts the change now.

   > -[Dictionary addObject] may do something reasonable if the argument
   > conforms to the <Associating> protocol :-) i.e. answering to -key and
   > -value etc.
  
  I could pull the -key and -value from an <Associating> object and
  insert them into the Dictionary, but the Dictionary would not keep the
  <Associating> object itself.  We might get in trouble if the user
  expected the Dictionary to keep track of the original <Associating>
  object.  I'm really not sure what to do here.  For now I'll nothing,
  but I'm open to more suggestions, or just convincing that this above
  behavior is fine.

If <Associating> objects have the constraint thet they're `isEqual:'
if their keys are `isEqual:' then it should be ok I believe.  However,
who'd ever use <Associating> objects anyway -- they belong in a
garbage collected language.
  
   > Why does the system depend on the assertion in +[Collection initialize]?
  
  sizeof(elt) must == sizeof(void*) because the compare and hash
  functions used by hash.c take void* arguments, and the entire elt
  needs to get into the compare and hash functions.  I'm a bit
  uncomfortable with these casts.  What if we rewrote hash.c to use
  elt's!  I bit scary,.. but it certainly would make libcoll's
  implementation cleaner.
  
The hash table should be recoded since it doesn't scale very well for
large tables.  I did one dynamic scalable hashtable a while back in
C++, which could possibly be used.  In any case, I think the hash
table should use elt's...   

  Hmm, I'm trying to remember why I thought it was so important that
  sizeof(id) == sizeof(elt)... I guess sizeof(id) will always ==
  sizeof(void*) anyway, n'est-ce pas?

Right.
  
   > The hashing needs an update.  You're welcome to send me patches.
  
  Let me know what you think we should do about the idea above (re. elt
  data type used in libcoll and void* used in hash.c).
  
I think it's fine.  Having realized this union matter there is no
other option!

/Kresten

From krab@iesd.auc.dk Sat May 22 12:07:53 1993
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA14162; Sat, 22 May 93 12:07:50 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA03524; Sat, 22 May 93 12:07:50 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA02466
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sat, 22 May 1993 18:07:19 +0200
Received: by xiv.iesd.auc.dk id AA09129
  (5.65c8/IDA-CLIENT/MD); Sat, 22 May 1993 18:07:30 +0200
Message-Id: <199305221607.AA09129@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk, burchard@geom.umn.edu
Subject: More comments...
Date: Sat, 22 May 1993 18:07:30 +0200


Collection

Why does -inject:byCalling: use a void* for the initial data?  

-inject:byCalling: should not return self, but "initialData".

-trueForAllByPerforming:in:
-trueForAllByPerforming:in:with:
-trueForAnyByPerforming:in:
-trueForAnyByPerforming:in:with:
 
 does not need the elements to be object, they are
 only applied as arguments to the given selector!

I've started writing a little docs.  I've invented the following for
Objective-C to allow inline documentation to be extracted.

** Verbatim TeXinfo code may be embedded using the prefix `//@' and
will extend to the following lines as long as they start with `//'.  Like
this:

  //@ @section{Objective-@TeX{}info}
  //  This is a section of verbatim @TeX{}info code. 
  //  It lasts as long as the lines begin with @code{//}

  // This is ignored.

** Documentation to methods may also be embeeded.  This is prefixed by
`//-' or `//+' and should be right before the method definition, like
this:

  //- Replace @emph{one} occurrence of @var{oldElement} with
  //  @var{newElement} in the receiving collection.  If
  //  @var{oldElement} is absent an error is signalled.  Returns self.

- (elt) replaceElement: (elt )oldElement with: (elt )newElement
{
  ...

//+ Initialize class @code{Collection}
+ initialize
{
   ...

I've not written a preprocessor yet, but this should be sufficient for
a start documenting!  I've documented half of class Collection like
this.

/Kresten

From mccallum Sat May 22 13:31:14 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305221607.AA09129@xiv.iesd.auc.dk>
CC: burchard@geom.umn.edu
Subject: More comments...

Kresten Krab Thorup writes:
 > Why does -inject:byCalling: use a void* for the initial data?  
 > -inject:byCalling: should not return self, but "initialData".

Yes, you're right.  inject:byCalling: now looks like:

- (elt) inject: (elt)initialData byCalling: (elt(*)(elt,elt))aFunc
{
  void doIt(elt e)
    {
        initialData = aFunc(initialData, e);
    }
  [self withElementsCall:doIt];
  return initialData;
}


 > -trueForAllByPerforming:in:
 > -trueForAllByPerforming:in:with:
 > -trueForAnyByPerforming:in:
 > -trueForAnyByPerforming:in:with:
 >  
 >  does not need the elements to be object, they are
 >  only applied as arguments to the given selector!

Really?  I've always wondered how smart it was to pass non-objects in
the with: argument of -perform:with:,... I mean the method is typed to
take an object... how safe is it to try to send something else?

 > I've started writing a little docs.  I've invented the following for
 > Objective-C to allow inline documentation to be extracted.
 > 
 > ** Verbatim TeXinfo code may be embedded using the prefix `//@' and
 > will extend to the following lines as long as they start with `//'.  Like
 > this:
 > 
 >   //@ @section{Objective-@TeX{}info}
 >   //  This is a section of verbatim @TeX{}info code. 
 >   //  It lasts as long as the lines begin with @code{//}
 > 
 >   // This is ignored.

I'm all for a code-to-documentation convention, but I would really
prefer that it be based on /* */, not //.  I don't want to have to
insert "//" all the time.  It's especially a pain when I'm editing
an entry, (i.e. changing the line length).  Can we use /* */ instead?

-- Andrew

From krab@iesd.auc.dk Sat May 22 15:17:00 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA14557; Sat, 22 May 93 15:16:58 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA03873; Sat, 22 May 93 15:16:57 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA03845
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sat, 22 May 1993 21:16:25 +0200
Received: by xiv.iesd.auc.dk id AA10066
  (5.65c8/IDA-CLIENT/MD); Sat, 22 May 1993 21:16:36 +0200
Message-Id: <199305221916.AA10066@xiv.iesd.auc.dk>
In-Reply-To: <9305221731.AA14617@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu
Subject: More comments...
Date: Sat, 22 May 1993 21:16:36 +0200


   > -trueForAllByPerforming:in:
   > -trueForAllByPerforming:in:with:
   > -trueForAnyByPerforming:in:
   > -trueForAnyByPerforming:in:with:
   >  
   >  does not need the elements to be object, they are
   >  only applied as arguments to the given selector!
  
  Really?  I've always wondered how smart it was to pass non-objects in
  the with: argument of -perform:with:,... I mean the method is typed to
  take an object... how safe is it to try to send something else?

I suppose you'll have to extract the right kind of element and use
that as argument -- i.e. a big switch on _description inside the loop
or something like that if you feel like doing something that ugly.
You can get around the perform:with: warning by using
objc_msg_lookup...
  
  I'm all for a code-to-documentation convention, but I would really
  prefer that it be based on /* */, not //.  I don't want to have to
  insert "//" all the time.  It's especially a pain when I'm editing
  an entry, (i.e. changing the line length).  Can we use /* */ instead?
  
I suggest we use both.

   /*@ ...
       ... */
or
   //@ 
   //

Where `@' may be other control characters to give specific semanthics.

Currently we'll use those:

  @  -- verbatim TeXinfo
  -  -- method documentation 

/Kresten  



From kelley@open.dal.ca Sat May 22 15:17:37 1993
X-VM-Attributes: [t nil nil nil nil]
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA14565; Sat, 22 May 93 15:17:34 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA03877; Sat, 22 May 93 15:17:33 -0400
Received: from server.open.Dal.Ca by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA28757@wookumz.gnu.ai.mit.edu>; Sat, 22 May 93 14:54:53 -0400
Received: by open.dal.ca id <46081>; Sat, 22 May 1993 15:54:42 -0300
Message-Id: <93May22.155442adt.46081@open.dal.ca>
From: Dan Kelley <kelley@open.dal.ca>
To: gnu-objc@gnu.ai.mit.edu
Subject: Re: Alpha release of Objective-C Collection library
Date: 	Sat, 22 May 1993 15:54:28 -0300

I notice in reading some of this a discussion of Strings being based on
these Collection library items.

Is there an alpha copy of a String object?  I am looking forward to
trying objc-c, and the most natural way for one of my projects to move
in this direction is to use a String object as the basis for an item I
now do clumsily with a struct.

If there is no String object yet, does anyone have a guess as to when
there might be one?  I'm not in a great rush (we don't have gcc 2.4
installed yet), but I do wonder whether some other passive readers of
this group might be waiting for Strings to use in their first
application.

Dan Kelley, Oceanography Department   |  kelley@open.dal.ca
Dalhousie University                  |  {uunet watmath}!dalcs!kelley
Halifax, Nova Scotia, CANADA, B3H 4J1 |  (902) 494-1694

From mccallum Sun May 23 15:21:58 1993 EDT
To: Dan Kelley <kelley@open.dal.ca>
CC: gnu-objc@gnu.ai.mit.edu
In-reply-to: <93May22.155442adt.46081@open.dal.ca>
Subject: Re: Alpha release of Objective-C Collection library

Dan Kelley writes:
 > Is there an alpha copy of a String object? 

Nope, not yet.  It would be nice to have a String class that conforms
to the <IndexedCollecting> protocol.  The easiest way to do this would
involve making String inherit from IndexedCollection, BUT it seems
like a waste of memory to include the _description and _keyDescription
instance variables in a String object.  What we really need is
something like Steve's third item on his wish list.

Steve_Naroff@NeXT.COM (Steve Naroff) writes:
> (3) Improve the support for protocols...allow behavior (i.e. generic
> code) to be associated with a protocol.

Anyway, a whole heirarchy of String objects would be good... NeXT's
looks nice.  I wonder if they would donate it... 

..in any case GNU Objective-C should eventually support NeXT's 
@"a constant string" convention for creating ConstantString objects.
(see /NextLibrary/Documentation/NextDev/ReleaseNotes/ObjC.rtf under 3.0)

-- Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275--2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From glaeske@plains.NoDak.edu Sun May 23 21:37:49 1993
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA17362; Sun, 23 May 93 21:37:46 -0400
Received: from plains.NoDak.edu by cayuga.cs.rochester.edu (5.61/x) id AA06612; Sun, 23 May 93 21:37:44 -0400
Received: by plains.NoDak.edu; Sun, 23 May 1993 20:37:39 -0500
Message-Id: <199305240137.AA18949@plains.NoDak.edu>
From: Brian Glaeske <glaeske@plains.NoDak.edu>
To: mccallum@cs.rochester.edu
Subject: ObjC collection classes
Date: Sun, 23 May 1993 20:37:39 -0500

Andrew,

I was in the middle of writing a List class for ObjC when I saw your's on
the archive site.

Here are some of my diffs to your List class that emulate the NeXT List
class better.

The reason I put in the extra methods similer to makeObjectsPerform: is that
some people in the NeXT community got a little angry at NeXT for changing
the behavior of these methods from 2.x to 3.x of NeXTStep.

The change I made to -empty is that the NeXT version (at least in 3.x)
doesn't reduce the capacity of the list.  The realloc library call
doesn't (under SunOS4.1) the size of the memory area anyway.

I also added an if statement to -isEqual: to check if the count of the Lists
being compared is the same.  I figure that it is a quick check for something
that immediatly reports whether one criteria for equality is false.

Sincerely,
Brian Glaeske

--List.h.patch
85,88c85,86
< - makeObjectsPerform:(SEL)aSel;
< - makeObjectsPerform:(SEL)aSel with:anObject;
< - makeObjectsPerform:(SEL)aSelector byIndex:(BOOL)increasing;
< - makeObjectsPerform:(SEL)aSelector with:anObject byIndex:(BOOL)increasing;
---
> - makeObjectsPerform:(SEL)aSelector;
> - makeObjectsPerform:(SEL)aSelector with:anObject;

--List.m.patch
27,32d26
< /*
<  * Comment this line if you want NeXT's default behavior for
<  * -makeObjectsPerform: and -makeObjectsPerform:with: methods.
<  */
< #define INCREASING
< 
122,125c116,117
<   if ( ! [anObject isKindOf:[List class]] ) return NO;
< 
<   if ([self count] != [anObject count]) return NO; // Quick if they don't have the same count.
< 
---
>   if ( ! [anObject isKindOf:[List class]] )
>     return NO;
293,295d284
<   int i;
< 
<   for(i=0;i<numElements;i++) dataPtr[i] = nil;
296a286,287
>   maxElements = 2;
>   OBJC_REALLOC(dataPtr, id, maxElements);
323,330c314,318
< 	return [self makeObjectsPerform:aSel byIndex:
< #ifdef INCREASING
< YES
< #else
< NO
< #endif
< ];
< 
---
>   int i;
>   
>   for (i = 0; i < numElements; i++)
>     [dataPtr[i] perform:aSel];
>   return self;
335,384c323,327
< 	return [self makeObjectsPerform:aSel with:anObject byIndex:
< #ifdef INCREASING
< YES
< #else
< NO
< #endif
< ];
< 
< }
< 
< - makeObjectsPerform:(SEL)aSelector byIndex:(BOOL)increasing
< {
< 	int x;
< 
< 	if (increasing == NO) {
< 		for(x=numElements-1;x>=0;x--) { // Check the loop
< 			if ([(dataPtr[x]) respondsTo:aSelector] == YES) {
< 				[(dataPtr[x]) perform:aSelector];
< 			}
< 		}
< 	} else {
< 		for(x=0;x<numElements;x++) {
< 			if ([(dataPtr[x]) respondsTo:aSelector] == YES) {
< 				[(dataPtr[x]) perform:aSelector];
< 			}
< 		}
< 	}
< 
< 
< 	return self;
< }
< 
< - makeObjectsPerform:(SEL)aSelector with:anObject byIndex:(BOOL)increasing
< {
< 	int x;
< 
< 	if (increasing == NO) {
< 		for(x=numElements-1;x>=0;x--) { // Check the loop
< 			if ([(dataPtr[x]) respondsTo:aSelector] == YES) {
< 				[(dataPtr[x]) perform:aSelector with:anObject];
< 			}
< 		}
< 	} else {
< 		for(x=0;x<numElements;x++) {
< 			if ([(dataPtr[x]) respondsTo:aSelector] == YES) {
< 				[(dataPtr[x]) perform:aSelector with:anObject];
< 			}
< 		}
< 	}
< 	return self;
---
>   int i;
>   
>   for (i = 0; i < numElements; i++)
>     [dataPtr[i] perform:aSel with:anObject];
>   return self;

From mccallum Mon May 24 11:15:03 1993 EDT
To: Brian Glaeske <glaeske@plains.NoDak.edu>
In-reply-to: <199305240137.AA18949@plains.NoDak.edu>
Subject: ObjC collection classes

Hi Brian,

Thanks for the help with the List object.  I added all your
suggestions. 

I did however, make some modifications.  

I named the new methods 
  - makeObjectsPerform:(SEL)aSel reverseOrder:(BOOL)flag;
  - makeObjectsPerform:(SEL)aSel with:anObject reverseOrder:(BOOL)flag;
because I thought they were more descriptive.  If you feel strongly
about your original method names, let me know.

I also removed the check for [.. respondsTo:] in the
-makeObjectsPerform.. methods in order to be strictly compatible with
NeXT's List class.

Thanks again!
        Andrew


From krab@iesd.auc.dk Mon May 24 13:35:58 1993
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA20121; Mon, 24 May 93 13:35:53 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA09165; Mon, 24 May 93 13:35:51 -0400
Received: from eos.iesd.auc.dk by iesd.auc.dk with SMTP id AA27533
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 24 May 1993 19:35:15 +0200
Message-Id: <199305241735.AA27533@iesd.auc.dk>
Received: by eos.iesd.auc.dk (4.1/SMI-4.1)
	id AA10967; Mon, 24 May 93 19:36:12 +0200
In-Reply-To: <9305241715.AA19549@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Subject: hash.[hc]
  
  Do you have any plans to update hash.[hc] to use elt's?
  
  I'm not particularly anxious to do it myself, but I sure could use
  such a thing soon. :-)
Date: Mon, 24 May 1993 19:35:15 +0200

Eventually I will rewrite it completely as I think I've already
described to you.  If not earlier, this will happen in a month or so
when I finish my exams.

I am wondering if we should consider elt's some new type introduced in
the support system and promote it to be named capital `ELT' more in
the style of `SEL' and `IMP'.  This way there is also a smaller risk
to have a name conflict with existing code.


From mccallum Mon May 24 13:51:38 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305241735.AA27533@iesd.auc.dk>
Subject: hash.[hc]

Kresten Krab Thorup writes:
 > Eventually I will rewrite it completely as I think I've already
 > described to you.  If not earlier, this will happen in a month or so
 > when I finish my exams.

OK.  I think I'm going to throw together a quick hack that let's me
use (int(*)(elt,elt)) comparison functions and (unsigned(*)(elt)) hash
functions.  A proper change that would be folded into the objc runtime
can happen later.

 > I am wondering if we should consider elt's some new type introduced in
 > the support system and promote it to be named capital `ELT' more in
 > the style of `SEL' and `IMP'.  This way there is also a smaller risk
 > to have a name conflict with existing code.

I feel pretty neutral about this.  Whatever other people want.

- Andrew


From Steve_Naroff@NeXT.COM Sat May 22 18:37:47 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA14902; Sat, 22 May 93 18:37:44 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA04179; Sat, 22 May 93 18:37:43 -0400
Received: from next.com by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA00376@wookumz.gnu.ai.mit.edu>; Sat, 22 May 93 18:17:27 -0400
Received: from nomad by oz.NeXT.COM (NX5.67d/NeXT0.1-Aleph-bf)
	id AA11975; Sat, 22 May 93 15:17:13 -0700
Message-Id: <9305222217.AA11975@oz.NeXT.COM>
Received: by nomad.next.com (NX5.67d/NX3.0X)
	id AA11499; Sat, 22 May 93 15:17:12 -0700
Received: by NeXT.Mailer (1.95)
Received: by NeXT Mailer (1.95)
From: Steve_Naroff@NeXT.COM (Steve Naroff)
To: bcox@gmu.edu (Brad Cox)
Cc: gnu-objc@gnu.ai.mit.edu, Kresten Krab Thorup <krab@iesd.auc.dk>,
        "Mark C. Carroll" <carroll@udel.edu>bof@midget.saar.de
Subject: Re: why doesn't this work? :)
Date: Sat, 22 May 93 15:17:12 -0700


Brad> If you're going to tinker with a language, do so only for  
something substantial. 


I agree with you. The 3 features on my groups wish list are:

(1) Exception Handling...allows errors to be handled in a context  
dependent manner (please, no "printf's"!).
(2) Namespace support...allows independently developed libraries to  
be used without fear of name collisions.
(3) Improve the support for protocols...allow behavior (i.e. generic  
code) to be associated with a protocol.

In my mind, all three are key to providing better "packaging  
mechanisms" with the goal of developing more reusable objects.

I think blocks are interesting, however they aren't requested as  
often as the features previously listed.

I will send email to the group when we have a preliminary  
specification for any of these features.
 

Anyway, if you have any thoughts on any of these features, it would  
be great to hear from you.

regards, snaroff.

From krab@iesd.auc.dk Sun May 23 09:27:37 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16063; Sun, 23 May 93 09:27:32 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA05493; Sun, 23 May 93 09:27:28 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA12130
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sun, 23 May 1993 15:26:59 +0200
Message-Id: <199305231326.AA12130@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA07242; Sun, 23 May 93 15:27:31 +0200
In-Reply-To: <9305221945.AA15432@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: More comments...
Date: Sun, 23 May 1993 15:26:59 +0200

  I suppose the REAL "RIGHT THING TO DO" (TM) :-) is to look at the types
  that the SEL expects.  It would be nice to have easy macros for
  finding out the number and types of the arguments a method expects.

I'll soon discard the 'archive.c' of the objc runtime and replace it
with the Objective C implementation.  More over, I am working on a set
of functions to manipulate encodings 'encoding.c'.  I'll include it in
the bottom of this message in case you can use some of it.

  I wonder if we could even write macro, something like
  DECLARE_IMP(aFuncPtr, aSEL)
  that would create a fuction pointer variable of the correct type.
  It would expand into something that effectively did the following:
  int (*aFuncPtr)(id,SEL,float);

I am working on a special verbose kind of argframe that contains type
information -- something like:

  typedef struct {
    unsigned int flags;
    unsigned int size;
    const char* typespec;
    char* datum;
  } __objc_arg;

  typedef struct {
    unsigned int nargs;
    __objc_arg rettype;
    __objc_arg args[1];
  } __objc_argframe;

With accompanying macros/functions and the ability to apply a such
argframe to a function pointer.  This will also be useful for the
distributed objects.

  Unfortunately it's also probably impossible to write.

Not quite, just close to.  

   > I suggest we use both.
   > 
   >    /*@ ...
   >        ... */
   > or
   >    //@ 
   >    //
  
  Both options!  Sounds great.

Here are some more:

  //$  -- variable "has a value"
  //#  -- define "#define ..."
  //!  -- C function "something happens"
  //@  -- Verbatim TeXinfo "All TeXinfo is just @'s"
  //-  -- ObjC methods "They often start with -"
  //=  -- ObjC classes "Old ObjC used = for @implementation"
  //{  -- struct 

All such comments, when connected to some specific declaration or
definition should appear *right before* that declaration.  We'll worry
about how to actually extract the documentation later, but thi should
be sifficient for now.

/Kresten

/*                               -*- Mode: C -*- 
 * 
 * encoding.c -- runtime encoding manipulation
 * 
 * $Id: DISCUSSION,v 1.1 1994/11/04 16:26:58 mccallum Exp $
 * 
 * Author          : Kresten Krab Thorup
 * Created On      : Fri May 14 18:43:04 1993
 * Last Modified By: Kresten Krab Thorup
 * Last Modified On: Sun May 23 15:23:16 1993
 * 
 * Update Count    : 444
 * Buffer Position : 1
 * Minor Modes     : ( Fill)
 * 
 * $Log: DISCUSSION,v $
# Revision 1.1  1994/11/04  16:26:58  mccallum
# Initial revision
#
# Revision 1.1  1994/11/04  16:26:58  mccallum
# Initial revision
#
 * 
 */

/*@ @section Encoding Manipulation
 *  This file contains a set of functions that may be used to
 *  manipulate encodings of types, such as returned by
 *  @code{@@encoding(@var{typespec})}.
 *
 *  The actual encoding of types should be documented here!
 */

#include "objc/objc-api.h"

#define MAX(X, Y) (X>Y ? X : Y)  

inline int objc_aligned_size (const char* type);
int objc_sizeof_type(const char* type);
int objc_alignof_type(const char* type);
int objc_aligned_size (const char* type);
int objc_promoted_size (const char* type);
const char* objc_skip_type_qualifiers (const char* type);
const char* objc_skip_typespec (const char* type);

static inline int
atoi (const char* str)
{
  int res = 0;
  
  while (isdigit (*str))
    res *= 10, res += (*str - '0');

  return res;
}

/*!
** return the size of an object specified by type 
** [This should be placed in tables later]
*/

int
objc_sizeof_type(const char* type)
{
  switch(*type) {
  case _C_ID:
    return sizeof(id);
    break;

  case _C_CLASS:
    return sizeof(Class*);
    break;

  case _C_SEL:
    return sizeof(SEL);
    break;

  case _C_CHR:
    return sizeof(char);
    break;
    
  case _C_UCHR:
    return sizeof(unsigned char);
    break;

  case _C_SHT:
    return sizeof(short);
    break;

  case _C_USHT:
    return sizeof(unsigned short);
    break;

  case _C_INT:
    return sizeof(int);
    break;

  case _C_UINT:
    return sizeof(unsigned int);
    break;

  case _C_LNG:
    return sizeof(long);
    break;

  case _C_ULNG:
    return sizeof(unsigned long);
    break;

  case _C_PTR:
  case _C_ATOM:
  case _C_CHARPTR:
    return sizeof(char*);
    break;

  case _C_ARY_B:
    {
      int len = atoi(type+1);
      while (isdigit(*++type));
      return len*objc_aligned_size (type);
    }
    break; 

  case _C_STRUCT_B:
    {
      int acc_size = 0;
      int align;
      while(*type++ != '=');	/* skip "<name>=" */
      do
	{
	  align = objc_alignof_type (type);       /* padd to alignment */
	  if ((acc_size % align) != 0)
	    acc_size += align - (acc_size % align);
	  acc_size += objc_sizeof_type (type);   /* add component size */
	  type = objc_skip_typespec (type);	         /* skip component */
	}
      while (*type != _C_STRUCT_E);
      return acc_size;
    }
    
  default:
    abort();
  }
}


/*!
** return the alignment of an object specified by type 
** [this should be placed in tables later]
*/

int
objc_alignof_type(const char* type)
{
  switch(*type) {
  case _C_ID:
    return __alignof__(id);
    break;

  case _C_CLASS:
    return __alignof__(Class*);
    break;
    
  case _C_SEL:
    return __alignof__(SEL);
    break;

  case _C_CHR:
    return __alignof__(char);
    break;
    
  case _C_UCHR:
    return __alignof__(unsigned char);
    break;

  case _C_SHT:
    return __alignof__(short);
    break;

  case _C_USHT:
    return __alignof__(unsigned short);
    break;

  case _C_INT:
    return __alignof__(int);
    break;

  case _C_UINT:
    return __alignof__(unsigned int);
    break;

  case _C_LNG:
    return __alignof__(long);
    break;

  case _C_ULNG:
    return __alignof__(unsigned long);
    break;

  case _C_ATOM:
  case _C_CHARPTR:
    return __alignof__(char*);
    break;

  case _C_ARY_B:
    while (isdigit(*++type)) /* do nothing */;
    return objc_alignof_type (type);
      
  case _C_STRUCT_B:
    {
      struct { int x; double y; } fooalign;
      while(*type++ != '=') /* do nothing */;
      return MAX (objc_alignof_type (type), __alignof__ (fooalign));
    }
    
  default:
    abort();
  }
}

/*!
** The aligned size if the size rounded up to the nearest alignment.
*/

inline int
objc_aligned_size (const char* type)
{
  int size = objc_sizeof_type (type);
  int align = objc_alignof_type (type);

  if ((size % align) != 0)
    return size + align - (size % align);
  else
    return size;
}

/*!
** The size rounded up to the nearest integral of the wordsize
*/

inline int 
objc_promoted_size (const char* type)
{
  int size = objc_sizeof_type (type);
  int wordsize = sizeof (void*);

  if ((size % wordsize) != 0)
    return size + wordsize - (size % wordsize);
  else
    return size;
}

/*!
** Skip type qualifiers.  These may eventually precede typespecs
** occuring in method prototype encodings.
*/

inline const char*
objc_skip_type_qualifiers (const char* type)
{
  while (*type == 'r' || *type == 'n' || *type == 'N'
	 || *type == 'o' || *type == 'O' || *type == 'V')
    {
      type += 1;
    }
  return type;
}

  
/*!
** Skip one typespec element
*/

const char* 
objc_skip_typespec (const char* type)
{
  type = objc_skip_type_qualifiers (type);
  
  switch (*type) {

  case _C_ID:
    /* An id may be annotated by the actual type if it is known
       with the @"ClassName" syntax */

    if (*++type != '"')
      return type;
    else
      {
	while (*++type != '"') /* do nothing */;
	return type + 1;
      }

    /* The following are one character type codes */
  case _C_CLASS:
  case _C_SEL:
  case _C_CHR:
  case _C_UCHR:
  case _C_CHARPTR:
  case _C_ATOM:
  case _C_SHT:
  case _C_USHT:
  case _C_INT:
  case _C_UINT:
  case _C_LNG:
  case _C_ULNG:
  case _C_FLT:
  case _C_DBL:
  case _C_VOID:
    return ++type;
    break;

  case _C_ARY_B:
    /* skip digits, typespec and closing ']' */
    
    while(isdigit(*++type));
    type = objc_skip_typespec(type);
    if (*type == _C_ARY_E)
      return ++type;
    else
      abort();

  case _C_STRUCT_B:
    /* skip name, and elements until closing '}'  */
    
    while(*type++ != '=');
    do { type = objc_skip_typespec (type); } while (*type != _C_STRUCT_E);
    return ++type;

  case _C_PTR:
    /* Just skip the following typespec */
    
    return objc_skip_typespec (++type);
    
  default:
    abort();
  }
}


inline int
objc_typespec_length (const char* type)
{
  int length = 0;
  while (*type)
    {
      type = objc_skip_typespec (type);
      length += 1;
    }
  return length;
}






From krab@iesd.auc.dk Sun May 23 15:37:27 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA16684; Sun, 23 May 93 15:37:23 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA06064; Sun, 23 May 93 15:37:22 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA15668
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sun, 23 May 1993 21:36:51 +0200
Received: by xiv.iesd.auc.dk id AA17340
  (5.65c8/IDA-CLIENT/MD for mccallum@cs.rochester.edu); Sun, 23 May 1993 21:37:04 +0200
Message-Id: <199305231937.AA17340@xiv.iesd.auc.dk>
In-Reply-To: <9305231930.AA16894@vein.cs.rochester.edu>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Date: Sun, 23 May 1993 21:37:04 +0200

"mccallum@cs.rochester.edu"
CC: krab, burchard@geom.umn.edu
Subject: More comments... + objc2texi release -1


  I wonder if it wouldn't be useful to keep the NeXT-compatible
  functions around, and just use the functions in the Stream objects'
  implementations.  Someone also might want to deal with TypedStream's
  outside of Objective-C.

You're right that it would be usefull, but that means keeping two
implementations in sync *or* discarding the beautiful one in objc.

I've just done a first attempt on that documentation filter.  Pick it
up from iesd.auc.dk:/pub/ObjC/objc2texi-930523.tar.z

It's written in flex, and works as a filter... You need obstack.o from
the gcc distribution.

  flex objc2texi.flex
  gcc -c lex.yy.c
  gcc -o objc2texi lex.yy.o ~/gcc-2.4.0/obstack.o 

  objc2texi < readme-objc2texi

Wola!


From mccallum Sun May 23 15:21:58 1993 EDT
To: Dan Kelley <kelley@open.dal.ca>
CC: gnu-objc@gnu.ai.mit.edu
In-reply-to: <93May22.155442adt.46081@open.dal.ca>
Subject: Re: Alpha release of Objective-C Collection library

Dan Kelley writes:
 > Is there an alpha copy of a String object? 

Nope, not yet.  It would be nice to have a String class that conforms
to the <IndexedCollecting> protocol.  The easiest way to do this would
involve making String inherit from IndexedCollection, BUT it seems
like a waste of memory to include the _description and _keyDescription
instance variables in a String object.  What we really need is
something like Steve's third item on his wish list.

Steve_Naroff@NeXT.COM (Steve Naroff) writes:
> (3) Improve the support for protocols...allow behavior (i.e. generic
> code) to be associated with a protocol.

Anyway, a whole heirarchy of String objects would be good... NeXT's
looks nice.  I wonder if they would donate it... 

..in any case GNU Objective-C should eventually support NeXT's 
@"a constant string" convention for creating ConstantString objects.
(see /NextLibrary/Documentation/NextDev/ReleaseNotes/ObjC.rtf under 3.0)

-- Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625


From mccallum Mon May 24 11:15:03 1993 EDT
To: Brian Glaeske <glaeske@plains.NoDak.edu>
In-reply-to: <199305240137.AA18949@plains.NoDak.edu>
Subject: ObjC collection classes

Hi Brian,

Thanks for the help with the List object.  I added all your
suggestions. 

I did however, make some modifications.  

I named the new methods 
  - makeObjectsPerform:(SEL)aSel reverseOrder:(BOOL)flag;
  - makeObjectsPerform:(SEL)aSel with:anObject reverseOrder:(BOOL)flag;
because I thought they were more descriptive.  If you feel strongly
about your original method names, let me know.

I also removed the check for [.. respondsTo:] in the
-makeObjectsPerform.. methods in order to be strictly compatible with
NeXT's List class.

Thanks again!
        Andrew


From mccallum Mon May 24 13:15:12 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: hash.[hc]

Hi Kresten,

Do you have any plans to update hash.[hc] to use elt's?

I'm not particularly anxious to do it myself, but I sure could use
such a thing soon. :-)

- Andrew


From mccallum Mon May 24 13:51:38 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305241735.AA27533@iesd.auc.dk>
Subject: hash.[hc]

Kresten Krab Thorup writes:
 > Eventually I will rewrite it completely as I think I've already
 > described to you.  If not earlier, this will happen in a month or so
 > when I finish my exams.

OK.  I think I'm going to throw together a quick hack that let's me
use (int(*)(elt,elt)) comparison functions and (unsigned(*)(elt)) hash
functions.  A proper change that would be folded into the objc runtime
can happen later.

 > I am wondering if we should consider elt's some new type introduced in
 > the support system and promote it to be named capital `ELT' more in
 > the style of `SEL' and `IMP'.  This way there is also a smaller risk
 > to have a name conflict with existing code.

I feel pretty neutral about this.  Whatever other people want.

- Andrew


From mccallum Wed May 26 12:32:26 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305261610.AA12612@xiv.iesd.auc.dk>
Subject: Misc

Kresten Krab Thorup writes:
 >   (We still haven't heard from NeXT.  They might actually donate it.)
 > 
 > They talk.  Earlier they talked about donating various runtime stuff,
 > but it never happened.  It's too muche efford getting something from
 > them.  It's not that the developers don't see the point that there
 > software will be maintained, bugfixed and enhanced for free, it's the
 > managers... 

What a shame.   Well, perhaps this will give us a little more
flexibility to in making String conform to <IndexedCollecting>.

 > Well, I suggest "-includesSubsetOf:" is renamed to "-isSubsetOf:" and
 > recoded to:

I agree completely.  I just added your implementation of -isSubsetOf:
and I removed -includesSubsetOf:

 > I've packed down a snapshot and put it in /pub/ObjC/ForAndrew.tar.z

Thanks.  I got it.

 > I'm interested in knowing how much feedback you've gotten.  If you
 > code changes due to peoples feedback, I think it is important that the
 > turnaround time for releases is quite short, so that people will be up
 > to date and better be able to help you.  That's basically what I
 > wanted to assure.

Actually, I've gotten almost no feedback.  One person sent me some
suggestions for making List more compatible with NeXT's
implementation.  That's it.

Maybe we'll hear more from some of our NeXT-related gnu-objc members
after NeXT World Expo.

-- Andrew



From mccallum Thu May 27 10:47:08 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305270703.AA29867@iesd.auc.dk>
Subject: sendmsg.c


So, it looks to me like the *only* way to use the result of a performv
(or objc_msg_sendv) is to return it from -forward::

It looks to me like I can't do something like the following:
(admittedly bizarre behavior)

- forward: (SEL)aSel :(arglist_t)argFrame
{
  id ret;

  ret = [delegate performv:aSel :argFrame];
  if ([ret isFoo])
    return ret;
  else
    return nil;
}

Am I right?  

So in order not to be misleading, shouldn't -performv:: be typed as:
- (retval_t) performv:(SEL)aSel :(arglist_t)argFrame;


-- Andrew

  
From mccallum Thu May 27 12:56:11 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305271620.AA19995@xiv.iesd.auc.dk>
Subject: Questions on new release

Hi Kresten,

You're amazing.  Incredible.  What turn around time! :-)

I applied the patch, and all seems fine.  libcoll compiled and the
tests ran without problem.

I'm about to put another copy of libcoll on cs.rochester.edu for your
perusal.  It'll be there as pub/libForKresten.tar.z.  Reading
ChangeLog is probably the best way to understand the major changes.

I have some questions for you related to this version:


* What are the semantics of declaring
        - shallowCopyAs: (id <Collecting>)aCollectionClass;

Should I get a compile error when I say
        id foo = [array shallowCopyAs:[Object class]]; 

I don't.  And, in fact, the runtime error doesn't mention protocols
either.  It says, (just the standard "does not recognize" message):
        error: Object (instance)
        Object does not recognize initDescription:
        IOT trap

Does specifying (id <Collecting>) actually change (or mean)
anything??? 


* Take a look at tests/test5.m, especially at the implementation of 
- errorIndexRangeInSel: (SEL)aSel
    argList: (arglist_t)argFrame
    defaultReturn: (void *)valuePtr;

__builtin_return() seems to be returning a *pointer* to the returned
value, not the value itself.  What I've got works as I wanted it to;
it's just that __builtin_return() didn't behave as I thought it would.


* Yesterday, for the first time, I compiled libcoll with -Wall.  Wow,
it was great.  I found many small bugs.  There are some warnings I'm
having trouble getting rid of, though:

> KeyedCollection.m:379: warning: implicit declaration of function `printf'

I've included <stdio.h>, but 'printf' isn't there, believe it or not.
I could look into this more myself, but I seem to remember you asking
earlier about where to get a printf declaration from, and I thought
you might have some quick advice for me.

> ListLink.m:0: warning: `_OBJC_SELECTOR_TABLE' defined but not used

I have no idea what this is.

> Collection.m:1194: warning: incomplete implementation of class `Collection'
> Collection.m:1194: warning: method definition for `-conformsTo:' not found
> Collection.m:1194: warning: method definition for `-respondsTo:' not found
> Collection.m:1194: warning: class `Collection' does not fully implement the `C
ollecting' protocol

I've tried compiling with -Wno-protocol in order to get rid of these
bogus errors, but then I get complaints about *all* methods in the
protocol being missing.  Is this a bug in ss-930522?


Wow, things are really coming along, I think!  You've done an amazing
job.  I'm excited!

-- Andrew



From krab@iesd.auc.dk Thu May 27 16:18:20 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA08673; Thu, 27 May 93 16:18:18 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA25125; Thu, 27 May 93 16:18:16 -0400
Received: from eos.iesd.auc.dk by iesd.auc.dk with SMTP id AA08894
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Thu, 27 May 1993 22:17:29 +0200
Message-Id: <199305272017.AA08894@iesd.auc.dk>
Received: by eos.iesd.auc.dk (4.1/SMI-4.1)
	id AA27903; Thu, 27 May 93 22:18:40 +0200
In-Reply-To: <9305271656.AA11442@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: Questions on new release
Date: Thu, 27 May 1993 22:17:29 +0200

Andrew,

  You're amazing.  Incredible.  What turn around time! :-)

Most people would call me nuts.  Did you know that I am also deeply
involved in LaTeX3, co-sysadmin at my dept, student, author of teh AUC-TeX
environment for Emacs.  I have a 50MHz Life cycle!
  
  I applied the patch, and all seems fine.  libcoll compiled and the
  tests ran without problem.

Good.  I'll put it in 2.4.2 then.
  
  I'm about to put another copy of libcoll on cs.rochester.edu for your
  perusal.  It'll be there as pub/libForKresten.tar.z.  Reading
  ChangeLog is probably the best way to understand the major changes.
  
Thanx.


  * What are the semantics of declaring
	  - shallowCopyAs: (id <Collecting>)aCollectionClass;
  
  Should I get a compile error when I say
	  id foo = [array shallowCopyAs:[Object class]]; 

In my oppinion you ought to, since `Object' does not conform to the
Collecting protocol.
  
  I don't.  And, in fact, the runtime error doesn't mention protocols
  either.  

Protocols make no difference once the code is compiled.  If you want
to use them, you must use -conformsTo: explicitly.  However, I think
that other case above should be warned about.  Please make a minimal
test-case and mail it to wood@next.com. 

  __builtin_return() seems to be returning a *pointer* to the returned
  value, not the value itself.  What I've got works as I wanted it to;
  it's just that __builtin_return() didn't behave as I thought it would.

Please tell wood as well.  
  
  > KeyedCollection.m:379: warning: implicit declaration of function `printf'
  
  I've included <stdio.h>, but 'printf' isn't there, believe it or not.
  I could look into this more myself, but I seem to remember you asking
  earlier about where to get a printf declaration from, and I thought
  you might have some quick advice for me.

If it makes a difference for some OS/target, weither it is implicitly
defined or not, it will be declared in the headerfile stdio.h.  That's
what RMS answered me on the same question.
  
  > ListLink.m:0: warning: `_OBJC_SELECTOR_TABLE' defined but not used
  
This appears because you have a .m file with no message passing
`[me doThat:...]' constructs in it.  Please remind me of this once I
get finished with my exams..
  
  > Collection.m:1194: warning: incomplete implementation of class `Collection'
  > Collection.m:1194: warning: method definition for `-conformsTo:' not found
  > Collection.m:1194: warning: method definition for `-respondsTo:' not found
  > Collection.m:1194: warning: class `Collection' does not fully implement the `Collecting' protocol
  
  I've tried compiling with -Wno-protocol in order to get rid of these
  bogus errors, but then I get complaints about *all* methods in the
  protocol being missing.  Is this a bug in ss-930522?
  
Hmm... I guess we'll have to have a closer look at the protocols
typechecking as soon as I get a little more time.
  
  Wow, things are really coming along, I think!  You've done an amazing
  job.  I'm excited!
  
I'm excited as well. Your library really looks promising.

/Kresten

From krab@iesd.auc.dk Fri May 28 09:08:17 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA11540; Fri, 28 May 93 09:08:14 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA27946; Fri, 28 May 93 09:08:12 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA20135
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Fri, 28 May 1993 15:07:19 +0200
Received: by xiv.iesd.auc.dk id AA28304
  (5.65c8/IDA-CLIENT/MD); Fri, 28 May 1993 15:07:38 +0200
Message-Id: <199305281307.AA28304@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: krab@iesd.auc.dk
Subject: More : Misc <IndexedCollecting>
Date: Fri, 28 May 1993 15:07:38 +0200


new method for IndexedCollection:

- insertContentsOf: (id <Collecting>) aCollection atIndex: (unsigned)index
{
  void doIt(elt e)
    {
      [self insertElement: e atIndex: index];
    }
  if (aCollection == self)
    [[[self shallowCopy] withElementsInReverseCall:doIt] free];
  else
    [aCollection withElementsInReverseCall:doIt];
  return self;
}

How about adding methods that work on ranges?  In addition to, or to
replace, ..From:to: methods.  This would fit nicely into future String
class conforming to the <IndexedCollecting> protocol.

typedef struct _IndexRange { unsigned start; unsigned end; } IndexRange;

  - shallowCopyRange: (IndexRange)range;
  - replaceRange: (IndexRange)range with: (id <Collecting>)aCollection;
  - removeRange: (IndexRange)range;
  - (unsigned)indexOf{Element,Object}: anElem inRange: (IndexRange)range;
  ... think of more

Here's a great hack!  It's not portable to cast forth and back between
void* and integers.  This may add alignment padding on some machines
(urgh...) However, ptrdiff_t can be used as an integer, which will be
assured to be at least wordsize.  Thus, the following is far better
(from obstack.h):

#define ptr2int(PTR) ((PTR) - (char*)0)
#define int2ptr(INT) ((INT) + (char*)0)

Use that where ever possible.

I know this will require some work, but I'd *love* to see
IndexedCollection's being able to start at arbitrary indices.  Not
just zero.  Like the idea?  Meybe `prependElement:' should lower the
minimum index ... hehe!

/Kresten

From mccallum Fri May 28 13:15:40 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305281307.AA28304@xiv.iesd.auc.dk>
Subject: More : Misc <IndexedCollecting>

Hi Kresten,

Kresten Krab Thorup writes:
 > new method for IndexedCollection:
 > - insertContentsOf: (id <Collecting>) aCollection atIndex: (unsigned)index

Good idea.  It's now in there (with a correction the makes sure that
aCollection responds to -withElementsInReverseCall:, and calls
-withElementsCall: instead if it doesn't.)

 > How about adding methods that work on ranges?  In addition to, or to
 > replace, ..From:to: methods.  This would fit nicely into future String
 > class conforming to the <IndexedCollecting> protocol.
 > 
 > typedef struct _IndexRange { unsigned start; unsigned end; } IndexRange;

I would like to everything possible to make <IndexedCollecting> and
Strings work well together.  And I also believe that following NeXT's
String classes is a good idea.  ...so I suppose this means that it
makes sense to use "range" arguments, as NXString does.  I just wish
it were possible to pass in range arguments without having to declare
a structure variable to hold them.  i.e. wouldn't it be nice to be
able to say:
        [foo shallowCopyRange:{3,6}];           /* A */
instead of having to do:
        struct IndexRange r = {3,6};            /* B */
        [foo shallowCopyRange:r];
Since we can't do /* A */, it may be nice to keep the option of using
individual arguments, .i.e.:
        [foo shallowCopyFromIndex:3 to:6];
BUT, I'm not wild about crowding the API with two versions of all the
methods that use ranges.  *Sigh*  I'm not sure what to do.

Right now I'm leaning towards using range structure arguments, and
removing the "from:to:" methods.  I wonder if someday gcc will be able
to do /* A */ ?  I'll sleep on this decision a bit before I jump in
and make a lot of changes.

An even bigger issue in the relationship between String's and libcoll,
is how to make effective use of all the protocol methods implemented
in Collection, KeyedCollection and IndexedCollection without requiring
that String waste memory by having the instance variables _description,
_comparison_function and _keyDescription.  

One solution would involve taking these instance variables out; adding
the method
        - (int) compareElements: (elt)e1 :(elt)e2;
and making this method, as well as
        - (const char *) contentsDescription;
        - (const char *) keyDescription;
subclass responsibilities.  The concrete subclasses would all have to
declare their own instance variables to hold the required data.  This
would be a little unfortunate, but I'm not sure what else to do.
Although in some ways it's not very clean, in other ways it is a
little *more* clean.  It also allows more flexibility in the way
elements are compared (instance variables of the Collection can now be
accessed during the compare---potentially very useful.)

So, do you have someone working on the String heirarchy now?  If you
don't have anyone, I would be willing to work on it (would enjoy it,
actually), but I wouldn't be able to do much on it until the beginning
of July.

 > Here's a great hack!  It's not portable to cast forth and back between
 > void* and integers.  This may add alignment padding on some machines
 > (urgh...) However, ptrdiff_t can be used as an integer, which will be
 > assured to be at least wordsize.  Thus, the following is far better
 > (from obstack.h):
 > 
 > #define ptr2int(PTR) ((PTR) - (char*)0)
 > #define int2ptr(INT) ((INT) + (char*)0)
 >
 > Use that where ever possible.

Looks neat, but I don't know where I would use it.  Am I casting
between void*'s and int's anywhere in libcoll?

 > I know this will require some work, but I'd *love* to see
 > IndexedCollection's being able to start at arbitrary indices.  Not
 > just zero.  Like the idea?  Meybe `prependElement:' should lower the
 > minimum index ... hehe!

Hmmm,.. really?  I do see it as an added feature, but so far I fail to
see that its usefulness would outweigh the potential messiness
(messiness in API as well as implementation).  ...I guess I just want
to be careful not to get too carried away.  I'm open to more
convincing arguments, though.

Later, my friend,
        Andrew


From krab@iesd.auc.dk Sat May 29 05:22:28 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA15954; Sat, 29 May 93 05:22:25 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA02224; Sat, 29 May 93 05:22:22 -0400
Received: from eos.iesd.auc.dk by iesd.auc.dk with SMTP id AA02316
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sat, 29 May 1993 11:21:28 +0200
Message-Id: <199305290921.AA02316@iesd.auc.dk>
Received: by eos.iesd.auc.dk (4.1/SMI-4.1)
	id AA23281; Sat, 29 May 93 11:22:45 +0200
In-Reply-To: <9305281715.AA16468@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Subject: More : Misc <IndexedCollecting>
Date: Sat, 29 May 1993 11:21:28 +0200

Andrew,

  i.e. wouldn't it be nice to be
  able to say:
	  [foo shallowCopyRange:{3,6}];           /* A */
  instead of having to do:
	  struct IndexRange r = {3,6};            /* B */
	  [foo shallowCopyRange:r];

Until gcc some day might be able to do /*A*/, the following macro will
be a pretty good replacement:

  #define Range(START,END) ({ IndexRange __ir = {(START), (END)}; __ir; })

Other macroes for comparing and testing range relationships as sets of
indices would be nice:

  #define RangeInside(A,B) \
    ({IndexRange __a=(A), __b=(B); __a.start<=__b.start && __a.end>=__b.end;})

  ...and friends.

  Right now I'm leaning towards using range structure arguments, and
  removing the "from:to:" methods.  I wonder if someday gcc will be able
  to do /* A */ ?  I'll sleep on this decision a bit before I jump in
  and make a lot of changes.

In my oppinion we should avoid having both.  Ranges are nice, since
they can also be returned from methods.  If you define it as:

 typedef struct {
    unsigned int start : sizeof(long)*8/2;
    unsigned int end : sizeof(long)*8/2;
 } IndexRange;

it will fit in one word, and will be rather cheap to pass as an
argument.  However, on machines with strict alignment such as the
sparc, it will be a little more expensive extracting (accessing) the
elements.
  
  One solution would involve taking these instance variables out; adding
  the method
	  - (int) compareElements: (elt)e1 :(elt)e2;
  and making this method, as well as
	  - (const char *) contentsDescription;
	  - (const char *) keyDescription;
  subclass responsibilities.  The concrete subclasses would all have to
  declare their own instance variables to hold the required data.  This
  would be a little unfortunate, but I'm not sure what else to do.

If you add private methods to set and get those as `virtual instance
variables' you could keep the nice initDesc... structure of methods.
It wouldn't be too unfortunate, since they're not accessed very often.
I suggest:

  - (int(*)(elt,elt))comparisonFunction;
  - comparisonFunction:(int(*)(elt,elt))aFunction;
  - (const char*)contentsDescription;
  - contentsDescription:(const char*);
  - (const char*)keyDescription;
  - keyDescription:(const char*);

So you can keep the neat structure of initializers.

  So, do you have someone working on the String heirarchy now?  If you
  don't have anyone, I would be willing to work on it (would enjoy it,
  actually), but I wouldn't be able to do much on it until the beginning
  of July.

Well, he (cheng@iesd.auc.dk) has started doing it, but he's quite new
to objc.  Let's give him a change, I'll help him, and then wait and
see how it is in a month or so.  If you will not have time during the
next month, it will at least not make any difference.
  
  Looks neat, but I don't know where I would use it.  Am I casting
  between void*'s and int's anywhere in libcoll?

In the enumerators of IndexedCollection `void **enumState' you do such
casts.  Like `(unsigned)(*enumState).'  E.g. the following should be
rewrittien to:

- (BOOL) getNextElement:(elt *)anElementPtr withEnumState: (void**)enumState
{
  unsigned *eState = (unsigned*)enumState;
  if ((*eState) > [self count]-1)
    return NO;
  *anElementPtr = [self elementAtIndex:*eState];
  (*eState) += 1;
  return YES;
}

This is not an application of ptr2int, I know, but this is more
portable, since you avoid casts of pointers to integers.  Casts
between pointers is not dangerous.  Thus:

   void **x;
   unsigned b = ((unsigned)(*x));  /* bad */
   unsigned a = *((unsigned*)(x)); /* good */
  
   > I know this will require some work, but I'd *love* to see
   > IndexedCollection's being able to start at arbitrary indices.  Not
   > just zero.  Like the idea?  Meybe `prependElement:' should lower the
   > minimum index ... hehe!
  
  Hmmm,.. really?  I do see it as an added feature, but so far I fail to
  see that its usefulness would outweigh the potential messiness
  (messiness in API as well as implementation).  ...I guess I just want
  to be careful not to get too carried away.  I'm open to more
  convincing arguments, though.

It will not mess up the API (you should add a few extra initializers
to IndexedCollection), but the implementation would to some extend be
messed up.  All occurences of _contents_array[xx] should be replaced
by a macro expanding into `_contents_array[(xx)-_start_index]', that's
all as far as I can see.  But of cause, it's up to you.  I can *easily*
live without it.

Yours, 
Kresten

From mccallum Fri May 28 16:34:51 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Distributed Objects from NeXT


Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc
greg@afs.com (Gregory H. Anderson) writes:
> important in distributed, heterogeneous enterprise-wide environments.
> Avie hinted publicly in the Tuesday afternoon briefing that after the
> HP/UX version is complete, the source code may be made available for
> porting PDO to other environments. Also, this implementation will be
> CORBA compliant, another sign of how rapidly things are changing
> inside NeXT. Projected

Public source code for Distributed Objects.  We should find out what
the deal is here.

 -- Andrew


From mccallum Sat May 29 11:44:03 1993 EDT
To: Kresten Krab Thorup <krab@iesd.auc.dk>
In-reply-to: <199305290921.AA02316@iesd.auc.dk>
Subject: More : Misc <IndexedCollecting>

Hi Kresten,

Kresten Krab Thorup writes:
 > In my oppinion we should avoid having both.  Ranges are nice, since
 > they can also be returned from methods.  If you define it as:

Yup, after sleeping on it, I still think using just the range argument
methods will be best (i.e. I agree with you).  I'm going to make those
changes today.

 >  typedef struct {
 >     unsigned int start : sizeof(long)*8/2;
 >     unsigned int end : sizeof(long)*8/2;
 >  } IndexRange;
 > 
 > it will fit in one word, and will be rather cheap to pass as an
 > argument.  However, on machines with strict alignment such as the
 > sparc, it will be a little more expensive extracting (accessing) the
 > elements.

So, do you think I should go ahead and use this IndexRange def that
fits in one word?

 >   One solution would involve taking these instance variables out; adding
 >   the method
 >        - (int) compareElements: (elt)e1 :(elt)e2;
 >   and making this method, as well as
 >        - (const char *) contentsDescription;
 >        - (const char *) keyDescription;
 >   subclass responsibilities.  The concrete subclasses would all have to
 >   declare their own instance variables to hold the required data.  This
 >   would be a little unfortunate, but I'm not sure what else to do.
 > 
 > If you add private methods to set and get those as `virtual instance
 > variables' you could keep the nice initDesc... structure of methods.
 > It wouldn't be too unfortunate, since they're not accessed very often.

Yup, I alo want to keep the nice -initDescription... structure.  Wow,
I see this as a rather drastic change, and not entirely a beautiful
one since many different classes will now essentially declare the same
instance variables, BUT I suppose it is best for the String class.
Sigh.  I really hope that collections and the String classes end up
fitting well together so that this is worth it.  I'm going to make
these changes today also.

 >   So, do you have someone working on the String heirarchy now?  If you
 >   don't have anyone, I would be willing to work on it (would enjoy it,
 >   actually), but I wouldn't be able to do much on it until the beginning
 >   of July.
 > 
 > Well, he (cheng@iesd.auc.dk) has started doing it, but he's quite new
 > to objc.  Let's give him a change, I'll help him, and then wait and
 > see how it is in a month or so.  If you will not have time during the
 > next month, it will at least not make any difference.

OK.  Since the string class is so related to the collection library
stuff, I'd definitely like to be kept informed about the design
decisions and progress.

 >   Looks neat, but I don't know where I would use it.  Am I casting
 >   between void*'s and int's anywhere in libcoll?
 > 
 > In the enumerators of IndexedCollection `void **enumState' you do such
 > casts.  Like `(unsigned)(*enumState).'  E.g. the following should be
 > rewrittien to:

Thanks; you're right.  I just finished changing it.

-- Andrew


From krab@iesd.auc.dk Sat May 29 06:00:48 1993
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA24041; Sat, 29 May 93 06:00:46 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA02316; Sat, 29 May 93 06:00:38 -0400
Received: from eos.iesd.auc.dk by iesd.auc.dk with SMTP id AA02593
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sat, 29 May 1993 11:55:17 +0200
Message-Id: <199305290955.AA02593@iesd.auc.dk>
Received: by eos.iesd.auc.dk (4.1/SMI-4.1)
	id AA24097; Sat, 29 May 93 11:56:34 +0200
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: gnu-objc@gnu.ai.mit.edu
Subject: none -- less than nil
Date: Sat, 29 May 1993 11:55:17 +0200

I'm helping Andrew a bit, writing the GNU objc collection library.  In
this connection there is the need for expressing uninitialized data,
something that is not even nil.  In a lot of situations nil does make
some sense, but we need something that has absolutely no meaning.  In
NeXT's List class, this is called `LIST_NO_ELEMENT' and is defined as
(~0).  We call it COLL_NO_ELEMENT.  I would like to propose that the
Objective-C community adapt this as some kind of standard, calling it
`none'.  This is like an counterpart to nil, which gives a runtime
error when messages are sent to it. So, if we can agree on this, I'll
put it in objc.h, defined as something like

  #define none ((id)~(nil))

It would be great to have a standard for this.  I think this is
`substantial' enough, to make it worth the change.  A lot of other
mechanisms, like archiving, could then be able to cope with `missing
elements'. 

What do you think?

/Kresten

From burchard@horizon.gw.umn.edu Sun May 30 13:09:30 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA27041; Sun, 30 May 93 13:09:27 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA05097; Sun, 30 May 93 13:09:27 -0400
Received: from dialup-slip-1-93.gw.umn.edu by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA21262@wookumz.gnu.ai.mit.edu>; Sun, 30 May 93 12:20:04 -0400
Received: by horizon.gw.umn.edu (NX5.67c/NX3.0M)
	id AA00431; Sun, 30 May 93 11:19:09 -0500
Message-Id: <9305301619.AA00431@horizon.gw.umn.edu>
Received: by NeXT.Mailer (1.87.2)
Received: by NeXT Mailer (1.87.2)
Reply-To: burchard@geom.umn.edu
From: Paul Burchard <burchard@horizon.gw.umn.edu>
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: none -- less than nil
Date: Sun, 30 May 93 11:19:09 -0500

> I would like to propose that the Objective-C community
> adapt this as some kind of standard, calling it `none'.
> This is like an counterpart to nil, which gives a runtime
> error when messages are sent to it.

Does this mean an additional test in the message dispatch code?  If  
so, one would have to balance the benefits of this convention against  
the added cost to every message call.  Although the extra cost would  
be small, it can't be taken lightly since it affects everything.

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------






From mccallum Mon May 31 12:04:37 1993 EDT
To: gnu-objc@gnu.ai.mit.edu
In-reply-to: <199305290955.AA02593@iesd.auc.dk>
Subject: none -- less than nil

Kresten Krab Thorup writes:
 > I'm helping Andrew a bit, writing the GNU objc collection library.  In
 > this connection there is the need for expressing uninitialized data,
 > something that is not even nil.  

I should give you folks a little more context on what is needed in the
collection library.

Let me begin by saying that I really don't care if this "less than
nil" element becomes part of Objective-C generally.  I'm perfectly
happy to keep the definition local to the collection library.

Here's the issue; consider the following questions:

* What should be returned by 
  - detectObjectByPerforming: (SEL)aSel;
(with the same semantics as Smalltalk's "detect:" message) when no
object in the collection answers YES to the testing selector?

* What should be returned by
  - lastObject;
when the collection is empty?

* What should be returned by 
  - (unsigned) indexOfObject: anObject;
and it's more general form for all KeyedCollection's
  - (elt) keyElementOfElement: (elt)anElement;
when the argument is not present?  

* What should be returned by 
  - nextObject: (void**)enumState;
when the enumeration has already returned the last element in the
collection? 


In the current implementation COLL_NO_ELEMENT is returned, and it's
defined: 
  const elt COLL_NO_ELEMENT = ((elt)(~0L));

NeXT's List class returns nil in response to lastObject on an empty
list, but I'm not wild about that because we might want nil to be a
valid element of a collection (as in Smalltalk).

Because you can have collections that hold (long int)'s, no matter
what value I choose for COLL_NO_ELEMENT it will always be some valid
element.  Choosing (~0L) makes sense because it's an index value
that's never going to get used, (whereas the index 0, for instance,
gets used all the time).


There *are* ways of getting around this issue completely:  
  - detectObjectByPerforming: (SEL)aSel;
  - lastObject;
  - (elt) keyElementOfElement: (elt)anElement;
  - (unsigned) indexOfObject: anObject;
could all raise an exception when there is no valid value to be returned,

..and 
  - nextObject: (void**)enumState;
could be rewritten as
  - (BOOL) getNextObject: (id *)anObjectPtr withEnumState: (void**)state;
where the method returns NO when the enumeration is done.  (This is
what I had to do with non-object enumerations already anyway.)

BUT, I think both these changes reduce ease-of-use.  And frequent
patterns of calling "-(BOOL)includesObject:" before each
"-(unsigned)indexOfObject:" would really reduce efficiency.  Still, I
could be convinced to make these changes.

Well.  Now you know some of the collection library issues.  I'm open
to opinions and suggestions.

-- Andrew

P.S.

Kresten Krab Thorup <krab@iesd.auc.dk> writes:
> In NeXT's List class, this is called `LIST_NO_ELEMENT' and is defined
> as (~0).

FYI, there is no LIST_NO_ELEMENT; I think Kresten means 
  #define NX_NOT_IN_LIST        0xffffffff


 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625


From bungi@omnigroup.com Mon May 31 15:38:34 1993
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA00530; Mon, 31 May 93 15:38:31 -0400
Received: from yang.cpac.washington.edu by cayuga.cs.rochester.edu (5.61/x) id AA08273; Mon, 31 May 93 15:38:28 -0400
Received: from bungi.UUCP by yang.cpac.washington.edu
	(4.1/internet->uucp gateway 2.4.2) id AA10455; Mon, 31 May 93 12:40:36 PDT
Received: by bungi.omnigroup.com
	(NX5.67d/UW-NDC Revision: 2.21 ) id AA12776; Mon, 31 May 93 12:37:03 -0700
Message-Id: <9305311937.AA12776@bungi.omnigroup.com>
Received: by NeXT.Mailer (1.94)
Received: by NeXT Mailer (1.94)
Reply-To: omnigroup.com!bungi@bungi.omnigroup.com
From: Timothy J. Wood <bungi@omnigroup.com>
To: <mccallum@cs.rochester.edu>
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: none -- less than nil
Date: Mon, 31 May 93 12:37:03 -0700


  Perhaps, for maximum flexibility (and some speed gains), you could do  
something like this:

#define COLL_DEFAULT_NO_ELEMENT (0x7fffffff)
static elt collNoElement = COLL_DEFAILT_NO_ELEMENT;

@interface Collection
+ (elt) noElement;
+ setNoElement: (elt) newNoElement;
+ setDefaultNoElement;
...
@end

  This would allow the programmer to make the decision as to what particular  
value is the correct representation of 'none' in their collection.  I would  
support 0x7fffffff (or whatever INT_MAX is on that machine) as the default  
'none' since ((elt)(~0L)) = -1 on most machines.  This is far more likely to  
be a useful element than is INT_MAX.
  This would also allow some speedups in the case that the collection doesn't  
contain zero elements since you could do:

   [Collection setNoElement: nil];  /* aColl contains no nil objects */
   while (obj = [aColl nextObject: &enumState]) {
      ...
   }
   [Collection setDefaultNoElement]; /* back to default for everyone else */

instead of:

   while ((obj = [aColl nextObject: &enumState]) != collNoElement) {
      ...
   }

  Not a large savings, but I think the flexibility of allowing the user to  
determine what is 'none' is more important.

--
Tim Wood
The Omni Group



From 
Return-Path: gsk@marble.com
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA08842; Sat, 13 Mar 93 01:55:49 -0500
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/x) id AA23570; Sat, 13 Mar 93 01:55:40 -0500
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA00308@albert.gnu.ai.mit.edu>; Fri, 12 Mar 93 23:20:52 -0500
Received: from carrara (carrara.bos.marble.com) by life.ai.mit.edu (4.1/AI-4.10) id AA27363; Fri, 12 Mar 93 23:20:28 EST
Received: from pentelic.bos.marble.com (pentelic) by carrara with SMTP id AA00806
  (5.65c/IDA-1.4.4 for <gnu-objc@prep.ai.mit.edu>); Fri, 12 Mar 1993 23:12:12 -0500
Message-Id: <199303130412.AA00806@carrara>
Received: by pentelic.bos.marble.com (NX5.67c/NX3.0X)
	id AA01179; Fri, 12 Mar 93 23:17:52 -0500
From: "Geoffrey S. Knauth" <gsk@marble.com>
To: gnu-objc@prep.ai.mit.edu
Cc: staff@marble.com
Subject: gnu-objc project status, 12-Mar-93
Date: Fri, 12 Mar 93 23:17:52 -0500

GNU Objective-C Project Status Information, updated 12 March 1993.

We accept submissions of original code via:
  gnu-objc-submissions@prep.ai.mit.edu

If you wish to receive submissions for the purpose of testing and
enhancing GNU Objective-C, you may subscribe to the sublist via
gnu-objc-submissions-request@prep.ai.mit.edu.

   Contents:  goals resources managers compatibility legal-matters

---------------------------------------------------------------------------
GOALS OF THE GNU OBJECTIVE-C PROJECT

- to provide OBJECTIVE-C TOOLS as free software, under GNU Copyleft,
  with the relaxed restrictions of the libg++ license;

- MACHINE INDEPENDENCE:  the tools will run on any GNU system;

- SUPPORT FOR X, which, as free software, is GNU's windowing system;

- a RUNTIME SYSTEM.  Dennis Glatting <dglattin@trirex.com>
  submitted the first GNU Objective-C runtime library.  Richard Stallman
  <rms@gnu.ai.mit.edu> enhanced it and included it with GCC 2.3.2.
  Lately, Kresten Krab Thorup <krab@iesd.auc.dk> has completely
  rewritten the runtime, giving it the tender loving care it
  always needed, and soon this will become the official runtime.

- COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++ OBJECTS, so that the
  Objective-C library and libg++ can help each other; language
  enhancements to make this easy;

- a GRAPHICAL OBJECT-ORIENTED PROGRAMMING TOOL.  Those familiar with
  the NeXT computer would call it a kind of Interface Builder that
  will run on any GNU system, and that lacks the flaws of other
  interface builders.  This tool will produce stereotype code that
  does not need to be edited by the user, and which can be read back
  into the tool.  The tool will allow interfaces under construction
  to be tested with real objects.  Those familiar with the tremendously
  versatile Smalltalk programming environment would look for as many
  Smalltalk features as possible.

---------------------------------------------------------------------------
GNU OBJECTIVE-C RESOURCES

Hello `gzip' and `.z' -- Goodbye `compress' and `.Z'

  Because software patents now restrict the use of the `compress' program,
  GNU archives are being stored as `gzip' files with the `.z' extension.
  This is good news, since `gzip' makes smaller files than `compress'.

Mailing lists

  The GNU Objective-C project operates mailing lists.  To access them,
  send mail to:

    DISCUSSIONS
    gnu-objc@prep.ai.mit.edu		for messages everyone will see
    gnu-objc-request@prep.ai.mit.edu	{,un}subscribing, address corrections

    SUBMISSIONS
    gnu-objc-submissions@prep.ai.mit.edu
    gnu-objc-submissions-request@prep.ai.mit.edu

    RUNTIME (very technical)
    gnu-objc-runtime@prep.ai.mit.edu
    gnu-objc-runtime-request@prep.ai.mit.edu

Runtime library

  GCC has been able to compile Objective-C code for several years, due
  to work contributed by NeXT.  Thanks to Dennis Glatting and Richard
  Stallman, in late 1992 a runtime library for GNU Objective-C became
  available as part of GCC 2.3.2.

  Kresten Krab Thorup <krab@iesd.auc.dk> has now completely rewritten
  the runtime.  His leadership and hard work have produced the best
  runtime yet, and he is now responsible for all runtime issues.

Archives

  ftp

    prep.ai.mit.edu:/pub/gnu/gcc-2.3.3.tar.z
      The GNU C compiler, GCC, compiles C, C++, and Objective-C for
      a great many platforms, and this archive includes the GNU Objective-C
      runtime library.

    iesd.auc.dk:/pub/ObjC/objc-runtime.tar.z
      Beta copy of Kresten Krab Thorup's thoroughly rewritten
      and greatly improved runtime library.

    prep.ai.mit.edu:/pub/gnu/gnu-objc-issues-1.0.tar.z
      Citizens of the net have contributed dozens of truly useful
      ideas to this project.  This archive captures some of the best
      ones in separate files by topic.  This archive is maintained
      by Geoffrey Knauth <gsk@marble.com>.

    cygnus.com:~ftp/pub/objc-log
      This is an uncut archive of gnu-objc discussions.

  Sharing

    Archives are more useful when they are widely distributed.
    Therefore we welcome the addition of other sites as archive
    repositories.

Preliminary class library submissions

  You have to be a tester to receive these, as they are unreleased.

  List.  Class for storing objects in a list.
    Donated 13 January 1993 by Adam Fedor <fedor@focus.colorado.edu>.
    Latest revision 21 January 1993.

  RCString.  Reference Counting String class.
    Donated 19 January 1993 by Bruce Ediger.

  String.  String class.
    Donated 23 December 1992 by John Hassey <hassey@dg-rtp.dg.com>.

  Two Patches to GCC 2.3.3's runtime
    Donated 27 February 1993 by Paul Burchard <burchard@geom.umn.edu>.

Some Thanks GNUs

  NeXT

    Numerous individuals at NeXT have been helpful to the Free
    Software Foundation, and continue to play an active role in
    discussions on the future of Objective-C.  NeXT uses GCC as its
    compiler of choice, and contributes much of its Objective-C
    know-how to GCC.  In particular, we would like to thank
    Steve Naroff and Tom Wood for their fortitude and hard work.

  Kresten Krab Thorup <krab@iesd.auc.dk>
    
    By completely rewriting the runtime library, producing its third
    edition, and by submitting detailed papers explaining and
    defending his implementation ideas, Kresten has demonstrated
    leadership, energy and devotion, greatly accelerating and
    improving the runtime.

    If you want to help Kresten, get in touch with him directly.  He
    has definite goals for the runtime, about which you may read in
    the issues archive mentioned above.  Kresten also leads the
    technical runtime discussion on gnu-objc-runtime@prep.ai.mit.edu.

  Richard M. Stallman <rms@gnu.ai.mit.edu>

    RMS produced the second version of the runtime, and continues to
    oversee the thorniest technical issues, to ensure that GNU
    Objective-C remains in step with GCC's unsurpassed reputation for
    portability and performance.

  Dennis Glatting <dglattin@trirex.com>

    Dennis submitted the first FSF version of an Objective-C runtime
    library, and that single contribution of actual code effectively
    began the GNU Objective-C project (except for NeXT's original GCC
    enhancements for compiling Objective-C).

  Cygnus Support

    Gumby at Cygnus is archiving gnu-objc e-mail discussions.

  Brad Cox

    Brad Cox has submitted his ECOOP'91 paper on "Exception Handling
    and Object-oriented Programming."

  Telco Systems

    Ken Hammer-Hodges at Telco Systems, Inc., of Norwood, MA, is very
    interested in the development of Objective-C.  Telco hosted a talk
    by Brad Cox for the Boston Computer Society on February 26, 1993.

  Pieter Schoenmakers <tiggr@es.ele.tue.nl>
  Michael Brouwer <michael@urc.tue.nl>

    Pieter and Michael are working on interesting ideas for a good
    class library.

  Institute of Problems of Cybernetics of the Russian Academy of Sciences

    These are the keepers of GNU in Russia.  They are reading up on
    Objective-C and Smalltalk, and we are looking for mutually
    beneficial ways to make use of their great programming talent in
    our projects.  Valery Leshko <lvi@rcsp.msk.su> is our contact.

Bugs

  Reporting Bugs

    Richard Stallman writes, "If people find bugs in GCC, they should
    read the Bugs chapter in the GCC manual and then mail bug reports
    to bug-gcc@prep.ai.mit.edu.  That's the way to get a bug fixed.
    They should read the Bugs chapter so that they understand what
    sort of information the maintainers need."

Peripherally Related

  These listings are last because they are only peripherally related
  to the specific goals of the Free Software Foundation.

  Distributed Objects across platforms

    From time to time, NeXT has discussions with companies that seek
    open systems solutions to the implementation of distributed
    objects.  Sometimes companies may be willing to cooperate and
    share development costs and results.  For further information, you
    must contact NeXT.

  UHOOP Sources from the University of Houston

    Mike Mahoney <mahoney@csulb.edu> writes,
    "John Glover has some very nice examples of non-NeXTSTEP
    Objective-C programs for beginners in his UHOOP notes, at the
    sonata.cc.purdue.edu archive site."

Conferences

  There is a free software conference being held in Moscow, Russia,
  April 19-24, 1993.  Richard Stallman will be the honored guest.

  The conference welcomes papers on such topics as:

  - the current state of the GNU project and other FSF projects;
  - free software means information freedom and sharing;
  - free software portability in Open Systems environments;
  - user experiences with free software;
  - free software in education and training;
  - legal aspects of free software;
  - relevance of free software to NIS modernization and democracy;

  For further information, contact:

  Moscow
    Sergei Kuznetsov (co-chair)    +7 (095) 272-4425    kuz@ivann.delta.msk.su
    Peter Brusilovsky              +7 (095) 198-7055    plb@plb.icsti.su
    Dmitry Volodin                 +7 (095) 231-2129    dvv@hq.demos.su
  Boston
    Geoffrey S. Knauth (co-chair)  +1 (617) 891-5555    gsk@marble.com

---------------------------------------------------------------------------
GNU OBJECTIVE-C MANAGERS

The GNU Objective-C project has project managers.  Please contact
these persons if you would like to contribute work to their projects.

  RUNTIME
    Kresten Krab Thorup <krab@iesd.auc.dk>

  COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++
    We are looking for a manager of this group.
    To volunteer, please write the administrator (see below).

  OBJECT MAP
    Chris Petrilli <petrilli@gnu.ai.mit.edu>

  A GRAPHICAL OBJECT-ORIENTED PROGRAMMING TOOL
    Daniel LaLiberte <liberte@ncsa.uiuc.edu>

Geoffrey Knauth <gsk@marble.com> is the FSF Objective-C administrator.
The administrator's duties are to collect software, provide quality
control, obtain releases and certifications of authenticity from
authors, submit releases to the FSF, and ensure community support and
recognition.

---------------------------------------------------------------------------
GNU OBJECTIVE-C DOES NOT PLAN TO REIMPLEMENT NeXTSTEP(tm)

First of all, the Free Software Foundation and NeXT are on friendly
terms.  NeXT bundles the GNU C compiler (GCC) with their computer, and
NeXT has contributed many many Objective-C enhancements to GCC.  We
acknowledge that NeXT is largely responsible for the popularization of
the Objective-C language, and also recognize that many advocates for
Objective-C free software are programmers of NeXTSTEP systems striving
for leverage in a real world of open systems.  The following
statements from Richard Stallman, FSF Founder, are primarily addressed
to this group of developers.

   "The aim of this project is to produce a useful addition to the GNU
   operating system, of which GCC is part.  This means we are only
   interested in packages that could run on a GNU system--and thus,
   not in packages that depend on NeXTSTEP, as we cannot expect to
   have anything compatible with NeXTSTEP available.  Supporting
   extensions to a proprietary window system is not part of the GNU
   mission and would be a diversion of effort."

			       --and--

   "NeXTSTEP is a proprietary package used by a small subset of the
   community; it has free alternatives.  Code written for NeXTSTEP
   simply won't run on the GNU system; it won't even come close to
   being useful for the GNU system.  We don't plan to make a
   compatible replacement for NeXTSTEP in the GNU system."

   "The GNU project has limited resources, and we have to focus on the
   goal we are trying to achieve: a complete, coherent free software
   system.  There are millions of projects that would be useful for
   someone.  Only a few of them contribute to this goal; we don't have
   enough resources to do all of those few.  If we lack the discipline
   to say no to unrelated projects, our work will be scattered and
   will not achieve the goal."

---------------------------------------------------------------------------
GNU OBJECTIVE-C LEGAL MATTERS

Before the Free Software Foundation can accept code, we must ask
authors that they certify their authorship, that they disclaim
copyright, and that no other party claims copyright.  We must track
who wrote and who made significant changes to which programs and
functions.  This tracking is more important to the Register of
Copyrights than a description of a program's function.

It is also important that you not submit software that infringes on
someone else's patent.

You must avoid submitting code that is fundamentally like code which
you previously developed for someone else, unless you obtain a written
release from that person or company.

If you are ready to submit code for acceptance, we will send you the
appropriate papers and more detailed legal information.

In this era of expensive litigation over software copyrights and
software patents, it is unfortunately necessary that we deal with a
large administrative overhead to avoid legal problems and to assure
your continued access to free software.

You may be interested in the work of the League for Programming
Freedom.  Write to league@prep.ai.mit.edu for details.

From 
Return-Path: chris@stokeisland.ohi.com
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA00280; Mon, 31 May 93 14:29:05 -0400
Received: from uu5.psi.com by cayuga.cs.rochester.edu (5.61/x) id AA08038; Mon, 31 May 93 14:29:05 -0400
Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
        id AA29279 for ; Mon, 31 May 93 14:18:15 -0400
Received: by stokeisland.ohi.com (NX5.67d/3.2.012693-Object Horizons);
        id AA00971 for cs.rochester.edu!mccallum; Mon, 31 May 93 14:09:41 -0400
Message-Id: <9305311809.AA00971@stokeisland.ohi.com>
Received: by NeXT.Mailer (1.94.RR)
Received: by NeXT Mailer (1.94.RR)
Reply-To: chris@stokeisland.ohi.com
From: chris@stokeisland.ohi.com (Chris Traynor)
To: mccallum@cs.rochester.edu
Subject: Re: Objective-C library
Date: Mon, 31 May 93 14:09:41 -0400

Andrew:
	I'd like to get involved with the creation of the Objective-C library.  If  
there are any classes I can create for the project, please ask..



Cheers, 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|Christopher Traynor   | "...and then there were   |
|Object Horizons, Ltd. | none."                    |
|                      |                           |		
|flames welcome.       |                           |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|             Contract offers welcome!             |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From 
Return-Path: cheng@iesd.auc.dk
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA10616; Wed, 2 Jun 93 11:06:24 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/x) id AA07303; Wed, 2 Jun 93 11:06:23 -0400
Received: from falk.iesd.auc.dk by iesd.auc.dk with SMTP id AA00420
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Wed, 2 Jun 1993 17:05:13 +0200
Message-Id: <199306021505.AA00420@iesd.auc.dk>
Received: by falk.iesd.auc.dk (4.1/SMI-4.1)
	id AA14395; Wed, 2 Jun 93 17:05:55 +0200
In-Reply-To: <9305312355.AA25843@vein.cs.rochester.edu>
From: Ivan Cheng <cheng@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Subject: new libcoll
Date: Wed, 2 Jun 1993 17:05:13 +0200

Hi Andrew,

I have been very busy (actually I will be busy for a long time) but I
have taken a look at the string classes from the NeXT. Kresten and I
agreed that we should aim at a similar hierarchy which will inherit
from IndexedCollection since a string conceptually a fine indexed
collection.
We are thinking about how to implement the hierarchy. We wish to move
as much as possible (methods) into the top class (string) and we have
thought about moving instance variables down to the subclasses.
The idea is to implement the following hierarchy (not fixed yet):

                           String
                           /    \
               ------------      ---------------                  
               |                               |
     SimpleReadOnlyString                MutableString
       /            \                          |
ConstantString  UniquedString            ReadWriteString

Somewhere in the left branch we will use a structure like the one you
use in the current String in libcoll:

@interface String : IndexedCollection <ValueHolding>
{
	char *_contents_chars;
	unsigned _count;
}

In the rest of the hierarchy we consider to use a system which would
enable GC later (something like the RCString from Bruce Ediger.)
What do you think about this?
We would really like to hear your opinion and I expect to begin
implementing using your String class.

greetings
Ivan

From 
Return-Path: krab@iesd.auc.dk
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (5.61/x) id AA28080; Sat, 5 Jun 93 07:52:19 -0400
Received: from [130.225.48.4] by cayuga.cs.rochester.edu (5.61/x) id AA23702; Sat, 5 Jun 93 07:52:20 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA14629
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Sat, 5 Jun 1993 13:51:03 +0200
Message-Id: <199306051151.AA14629@iesd.auc.dk>
Received: by loke.iesd.auc.dk (4.1/SMI-4.1)
	id AA07212; Sat, 5 Jun 93 13:52:13 +0200
In-Reply-To: <9306041551.AA21090@vein.cs.rochester.edu> "mccallum@cs.rochester.edu"
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Subject: forwarded message from henry
Date: Sat, 5 Jun 1993 13:51:03 +0200

   The thing I like a lot about "Gnu" is that it ends in a lowercase
   letter.  This helps the beginning of the descriptive part of the class
   name stand out.  

I do not really like `Gnu' since `GNU' is the right thing.  You're
right about the case stuff, but GNU is GNU -- not Gnu :-)
   
   NeXT's "NX" prefix wasn't too bad in this respect because "X" is such
   an unusual character that it didn't get confused with the beginning of
   the descriptive name.  (Even the 'graphical look' of the letter 'X',
   helped because it stands out a bit.)

Exactly.  How about using `GO', for GNU Objective-C?  The `GO' has
almost the same properties as `NX'.  It can even be pronounced as a
word of its own, so you say `go-collection' when you read
GOCollection, GOArray, GOSet etc.

   I'm still open to other ideas.   ...and I don't imagine that I'll have
   final say in the matter anyway :-)  Let's think this one out clearly
   before we make any weird, drastic changes.
   
Sure.  We shall make sure we make the right choise..  We're in no big
hurry.

Regards,
Kresten      

From 
Return-Path: smw002!IBX.COM!bburton@uunet.UU.NET
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA11514; Tue, 15 Jun 93 11:09:04 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA14281; Tue, 15 Jun 93 11:09:00 -0400
Received: from relay1.UU.NET by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA13937@wookumz.gnu.ai.mit.edu>; Tue, 15 Jun 93 08:14:06 -0400
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA26923; Tue, 15 Jun 93 08:14:02 -0400
Received: from smw002.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 081328.2552; Tue, 15 Jun 1993 08:13:28 EDT
Received: from wks07030.ibc by IBX.COM (4.1/SMI-4.1)
	id AA10340; Tue, 15 Jun 93 07:50:34 EDT
Message-Id: <9306151150.AA10340@IBX.COM>
X-Mailer: ELM [version 2.3 PL11]
From: bburton@IBX.COM (Brian Burton)
To: gnu-objc@gnu.ai.mit.edu
Subject: long file names in objective-c lib
Date: Tue, 15 Jun 93 7:50:28 EDT

I'm porting the Objective-C library to an i486 system running 
Interactive Unix v3.0 at home and have run into a snag.  Unfortunately,
ISC's file system limits file names to 14 characters.
Several files in the library have longer names which
ISC truncates.  Obviously this prevents the library from
building correctly.

As a workaround, I'm going to write a perl script to abbreviate the 
long names and change the sources accordingly.  Is there any chance 
the standard distribution of the library could be changed to use 
shorter file names?  I know it wouldn't be as clean, but it would 
be more portable.

Thanks to all who have made this library project happen.  I, for
one, think the world is a better place because of the efforts of
the FSF.  More power to you!

++Brian

From 
Return-Path: rms@gnu.ai.mit.edu
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA15002; Tue, 15 Jun 93 13:12:42 -0400
Received: from mole.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA14841; Tue, 15 Jun 93 13:12:38 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA02040@mole.gnu.ai.mit.edu>; Tue, 15 Jun 93 12:26:04 -0400
Message-Id: <9306151626.AA02040@mole.gnu.ai.mit.edu>
In-Reply-To: <9306151150.AA10340@IBX.COM> (bburton@IBX.COM)
From: rms@gnu.ai.mit.edu (Richard Stallman)
To: bburton@IBX.COM
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: long file names in objective-c lib
Date: Tue, 15 Jun 93 12:26:04 -0400

GNU maintainers should make sure that all the file names used in GNU
releases are unique within 14 characters.  They should also be unique
on MSDOG, which truncates to 8 (or is it 9?) characters before a
period, and 3 characters after.  (The doschk utility is good for 
checking this.)

From 
Return-Path: ilink.de!eike@tmpmbx.netmbx.de
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA23185; Wed, 16 Jun 93 21:08:19 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA23366; Wed, 16 Jun 93 21:08:14 -0400
Received: from sunmbx.netmbx.de by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA01460@wookumz.gnu.ai.mit.edu>; Wed, 16 Jun 93 17:12:51 -0400
Received: by sunmbx.netmbx.de (/\==/\ Smail3.1.28.1)
	  from tmpmbx.netmbx.de with smtp
	  id <m0o64tQ-0008rYC>; Wed, 16 Jun 93 23:19 MET DST
Received: by tmpmbx.netmbx.de (/\==/\ Smail3.1.28.1 #28.6)
	  id <m0o64kA-0001MEC>; Wed, 16 Jun 93 23:10 MES
Received: from edgun by ilink.de with SMTP id AA07620
  (5.65c/IDA-1.4.4 for <gnu-objc@gnu.ai.mit.edu>); Wed, 16 Jun 1993 22:52:28 +0200
Received: by edgun id AA09479
  (5.65c/IDA-1.4.4 for gnu-objc@gnu.ai.mit.edu); Wed, 16 Jun 1993 22:52:26 +0200
Message-Id: <199306162052.AA09479@edgun>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: Eike Dierks <eike@ilink.de>
To: gnu-objc@gnu.ai.mit.edu
Subject: Re: long file names in objective-c lib
Date: Wed, 16 Jun 1993 22:52:26 +0200

I don't know if this topic is something that should be  
discussed in this list but maybe it's worth to throw some  
bandwith on it.

>> GNU maintainers should make sure that all the file names  
used in GNU releases are unique within 14 characters.  They  
should also be unique on MSDOG, which truncates to 8 (or is  
it 9?) characters before a period, and 3 characters after.

And MSDO? doesn't care about upper case/lower case.

But this usually leads to non descriptive names. In the  
context of ObjC where descriptive names are more often used   
than they were in the days of plain old C this seems to be  
not acceptable.

Remember the X-Object naming debate - Wasn't the easiest  
solution to use longer, more descriptive names ?

Isn't there a convention in ObjC to name class-source files  
like the classes they contain ? (What about for example a  
container class (9 chars), will it be named containe.m to  
stay CP/M compatible ?)

OK, I understand that GNU libraries have to be highly  
portable. But should the limitations of a file system lead  
to non-descriptive class names ?

Wouldn't it would be nice to have source with long names  
and an automated way of mapping to (short, nondesciptive)  
MSDO? names or will the world have to stick to short  
filenames for the next xx years because of compatibility  
reasons ?

- Is there a standard way of mapping longer names to  
shorter names ? (some kind of mapping tables or algorithms)

- Is it at all possible ? Is there someone out there who  
did some research on this ?

- Is there some kind of GNU support for this ?

- Is GNU software for MSDOS usually compiled by GNU  
compilers or do people frequently use other compilers ? Is  
this a supported way of compiling GNU software ? i.e.  
should GNU maintainers stay compatible with (brand name  
ommited)-C or is it enough to be compatible with  
(compileable by) GNU-CC ?

In an all GNU world there might be the possibility to teach  
gnu-cc how to map long names in source files to short (but  
unique) names in the file system.

However it would be better to have some kind of  
configuration utility to adapt to the local file naming  
conventions.

---
P.S. I would suggest not to start a thread on the ugliness  
of MS-whatever here.

From 
Return-Path: rms@gnu.ai.mit.edu
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA29435; Wed, 16 Jun 93 23:48:39 -0400
Received: from mole.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA23853; Wed, 16 Jun 93 23:48:35 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA07519@mole.gnu.ai.mit.edu>; Wed, 16 Jun 93 23:21:51 -0400
Message-Id: <9306170321.AA07519@mole.gnu.ai.mit.edu>
In-Reply-To: <199306162052.AA09479@edgun> (message from Eike Dierks on Wed, 16 Jun 1993 22:52:26 +0200)
From: rms@gnu.ai.mit.edu (Richard Stallman)
To: eike@ilink.de
Cc: gnu-objc@gnu.ai.mit.edu
Subject: Re: long file names in objective-c lib
Date: Wed, 16 Jun 93 23:21:51 -0400

    >> GNU maintainers should make sure that all the file names  
    used in GNU releases are unique within 14 characters.  They  
    should also be unique on MSDOG, which truncates to 8 (or is  
    it 9?) characters before a period, and 3 characters after.

    Remember the X-Object naming debate - Wasn't the easiest  
    solution to use longer, more descriptive names ?

Right.  I have chosen two totally different solutions to these
two different problems.

Each solution is good for the problem it applies to.  As for whether
the two solutions are similar or not, there is no reason to care about
that.

From 
Return-Path: burchard@geom.umn.edu
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA01682; Thu, 17 Jun 93 00:48:33 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/y) id AA23990; Thu, 17 Jun 93 00:48:29 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Wed, 16 Jun 1993 23:48:23 -0500
Message-Id: <9306170448.AA11664@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Wed, 16 Jun 93 23:48:20 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
From: burchard@geom.umn.edu
To: mccallum@cs.rochester.edu, Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: Linus_Upson@NeXT.COM
Subject: Is -shallowCopy better named -allocCopy?
Date: Wed, 16 Jun 93 23:48:20 -0500

In light of your experiences with the Collection classes, I think it  
would be a good idea to change the name of what is now called  
-shallowCopy to -allocCopy (as I originally intended), and to create  
a separate -shallowCopy message.  I am asking for your feedback on  
this before I propose it to the mailing list.

The basic problem is that "shallowCopy" is a meaningful term, and the  
runtime designer is therefore asking for trouble if this term is  
overloaded in the programmer's mind with the additional and  
incompatible meaning of "raw binary copy of first level structure".

Just as with the Collection classes, a programmer could quite  
reasonably think of a meaning for "shallowCopy" that does something  
beyond the raw binary operation.  However, risking the purity of the  
raw operation in this way undermines the whole intention of the  
improved copy protocol, which is to allow clean subclassing.

Here are some issues that could benefit from your experience.  If we  
do this, what should be the relationship between -allocCopy,  
-shallowCopy, and -copy?  Should they nest or be independent?  (My  
inclination would be to make -shallowCopy independent of -copy.)  In  
either case, since -shallowCopy itself should be properly  
subclassable, we need an analog of -deepen for it.  What should that  
message be called?  Is this whole thing getting too baroque, or is it  
after all a reasonable way to give programmers the hooks they need  
for management of real classes?  (Simplicity is a strong argument for  
making -shallowCopy independent of -copy.)

In one sense, everything here is basically harmless, because it's  
completely compatible with classes based on NeXT's runtime.  But I'd  
like to make sure that extensions we add for the GNU runtime are  
sufficiently powerful and useful that they can be used properly in  
real classes.

Thanks for your time,
--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------


From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA05561; Thu, 17 Jun 93 02:57:58 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA24261; Thu, 17 Jun 93 02:57:54 -0400
Received: from SERV02.SLAC.Stanford.EDU by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA13482@wookumz.gnu.ai.mit.edu>; Thu, 17 Jun 93 00:49:41 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU (PMDF #2896 )
 id <01GZGM52YT00001MJ6@SERV02.SLAC.STANFORD.EDU>; Wed, 16 Jun 1993 21:49:29 PDT
Received: by kaon.SLAC.Stanford.EDU (NX5.67d/NX3.0S) id AA20362; Wed,
 16 Jun 93 21:49:09 -0700
Message-Id: <9306170449.AA20362@kaon.SLAC.Stanford.EDU>
X-Envelope-To: gnu-objc@gnu.ai.mit.edu
Content-Transfer-Encoding: 7BIT
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
To: gnu-objc@gnu.ai.mit.edu
Subject: GNU Objective-C
Date: 16 Jun 1993 21:49:09 -0700

   I've just come back from the IEEE conference on Real Time Computing
in High Energy, Nuclear, and Plasma Physics held in Vancouver.   I went
to the conference to give a "Short Course" (3 lecture hours) on Object
Oriented Programming.   Of relavence to this group is (I think)...

- The first half of my lectures uses Objective-C as the language for
examples.  I do this because for people new to OOP, Objective-C
presents the concepts of OOP with very few language changes from C.
The result of my presentation was a keen interest in Objective-C
amongst many of the participants.  I claim in my lectures that they
can get Objective-C from GNU gcc, including the run-time.  However,
with gcc 2.4.x, it doesn't work at least for AIX and I'm not sure what
other platforms have been tested.  My plead to this group that is
doing the hard work is that there is very real interest in Objective-C
once people have been properly introduced to it.  But these
portability problems are serious, and I hope this group will take them
seriously.

- One of my 75 transparencies for the short course describes NeXT's 
implementation of distributed objects.   To a group interested in 
Real Time, this aroused much interest.   It is fairly obvious that
remote objects as done by NeXT fits nicely into the problems of
Real Time computing and the OOP approach to Real Time computing.
"fits nicely" is probably too mild, rather it seems almost ideal for
this environment.   GNU doesn't support distributed objects.   But if
it did someday, I think it would be a real winner!  I think I can see
how to implement NeXT's distributed objects.  The nature of Objective-C
makes it fairly straight forward (althought a lot of detail work). I don't
see how one can do it with another OOP language such as the popular C++.
Objective-C has an advantage over C++ because of its *real* late
binding.

   I mention these two items because I believe that GNU support for
Objective-C has great potential.  Not only in Real Time computing, but
in other fields as well, people want to go OOP but think that C++ is
their only reasonable choice.  For many of these people, Objective-C
is a better choice (IMHO) and the only realistic support for
Objective-C comes from GNU gcc.  Sorry, I don't consider Objective-C
coming from a small company such as Stepstone or the support from NeXT
as being realistic for most of the community.   And I say that being
a NeXT user with a personal acquitence with a Stepstone founder.  Only
GNU can make Objective-C a language *realistic* language.

   Objective-C is a great language for many problems.   GNU support
for this language can make it fly.   Keep up the good work!

From 
Return-Path: krab@iesd.auc.dk
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA12958; Mon, 21 Jun 93 16:56:27 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/y) id AA12640; Mon, 21 Jun 93 16:56:20 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA06124
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 21 Jun 1993 22:54:15 +0200
Received: by xiv.iesd.auc.dk id AA25376
  (5.65c8/IDA-CLIENT/MD for mccallum@cs.rochester.edu); Mon, 21 Jun 1993 22:54:58 +0200
Message-Id: <199306212054.AA25376@xiv.iesd.auc.dk>
In-Reply-To: <9305221945.AA15432@vein.cs.rochester.edu> (mccallum@cs.rochester.edu)
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: mccallum@cs.rochester.edu
Subject: Re: More comments...
Date: Mon, 21 Jun 1993 22:54:58 +0200


Long time ago, you wrote:
   I suppose the REAL "RIGHT THING TO DO" (TM) :-) is to look at the types
   that the SEL expects.  It would be nice to have easy macros for
   finding out the number and types of the arguments a method expects.

   I wonder if we could even write macro, something like
   DECLARE_IMP(aFuncPtr, aSEL)
   that would create a fuction pointer variable of the correct type.
   It would expand into something that effectively did the following:
   int (*aFuncPtr)(id,SEL,float);

   for later use with:
   aFuncPtr = (int(*)(id,SEL,float))objc_msg_lookup(object, aSEL);

   I think this would be extremely useful in lots of situations, and it
   would encourage good programming (i.e. not fundging on types).
   Unfortunately it's also probably impossible to write.

It would be impossible to do it as a macro, but probably not too hard
to make it a new primitive of gcc.  If so, what do tou think it should
be called?  You know that gcc already has `typeof', so perhaps
`@typeof'

  @typeof(<typespec> <selector>)

Like

  @typeof (Array* addObject:)
or
  @typeof (id <IndexedCollecting> objectAtIndex:)

would expand into (id(*)(id,SEL,id)) and (id(*)(id,SEL,unsigned))
repectively.  However, this is static information, but we could
arrange for the compiler to allow it to be used as an IMP.

/Kresten

From 
Return-Path: krab@iesd.auc.dk
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA24071; Tue, 22 Jun 93 12:13:06 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA16647; Tue, 22 Jun 93 12:12:59 -0400
Received: from iesd.auc.dk by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA21433@wookumz.gnu.ai.mit.edu>; Tue, 22 Jun 93 07:24:37 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA13976
  (5.65c8/IDA-1.5/MD for <gnu-objc@gnu.ai.mit.edu>); Tue, 22 Jun 1993 13:22:24 +0200
Received: by xiv.iesd.auc.dk id AA00759
  (5.65c8/IDA-CLIENT/MD); Tue, 22 Jun 1993 13:23:07 +0200
Message-Id: <199306221123.AA00759@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: Steve Naroff <snaroff@next.com>
Cc: krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
Subject: A portable marg_.. replacement
Date: Tue, 22 Jun 1993 13:23:07 +0200


This is a technical description of the background for my new portable
marg_.. replacement.  Comments and questions are welcome.

If you don't know what the marg_.. macroes are for, this is not the
palce to find out.  RTFM.

** Background

The marg_.. macros as part of NeXTs runtime system are far from
portable.  The macros have to have knowledge about how arguments are
passed on the specific target being used.  This is not desireable,
since it means that when porting the ObjC runtime, one will have to
re-code the marg_.. macros every time.

Another major problem in the marg_.. macros is that they cannot be
made to handle arguments passed in registers, since they should
supposedly be written in plain (Objective) C.

** Implementation

I have implemented a new portable replacement for these macros, in
which the general idea is to let gcc describe the argument layout, and
then write a generic machinery to handle the accessing of arguments.
Since this is based on the new gcc primitive __builtin_apply_args, I
will start out by explaining that.

The gcc manual says:

`__builtin_apply_args ()'
     This built-in function returns a pointer of type `void *' to data
     describing how to perform a call with the same arguments as were
     passed to the current function.

     The function saves the arg pointer register, structure value
     address, and all registers that might be used to pass arguments
     to a function into a block of memory allocated on the stack. 
     Then it returns the address of that block.

In a bit more detail, the pointer returned is pointing to a block
laied out like this:

  struct __gnu_c_args_block {
    void *stack_args_block;
  #ifdef STRUCT_VALUE
    void *struct_value_block;
  #endif
  #ifdef ARG_REGISTERS
    char regs_arg_block[N];
  #endif
  }

 * The `stack_args_block' point to the beginning of the stack segment
   where the arguments passed on the stack are placed.

 * The `struct_value_block' points to a preallocated stack segment used
   for placing structure return values

 * The `regs_arg_block' contain a copy of each of the registers that may
   have been used for passing arguments.  Where `N' is the commutative
   size of all such registers.

Of cause, the two latter apply only if such mechanisms are supported
and used on the given target machine.

The purpose of the marg_.. macros was to manipulate (i.e. extract or
change) arguments of a marg_frame.  A marg_frame is somewhat like the
`__gnu_c_args_block' presented above, only, it does not contain the
registers.

** The parameter layout descriptor

In order to accomplish such manipulations, the marg_.. macros rely on
a parameter layout description generated by the compiler.  This
description states the stack offset and the type of each actual
argument.  For example, an integer argument passed on stack offet 16
may look like:

	"i16"

The full layout description is a sequence of such, plus a description
of the return type, and the size of all the arguments together.

The scheme has to be extended to be able to describe both stack
offsets, and offsets into the `regs_arg_block' as part of the
structure above.  I suggest we introduce additional syntax, so that
arguments passed in registers (which are thus copied to the
regs_arg_block) is described as the type encoding, a `+' character and
the offset into the block.  Like:

	"@+4"

Is an `id' parameter passed in a register which value is present at
offset 4 into the regs_arg_block.


** The proposal

So, to generalize the new proposal, here is how offsets are
interpreted:

 <type><offset>  

   Argument is placed at offset <offset> relative to the
   `stack_args_block' pointer part of the  __gnu_c_args_block.

 <type>+<offset>

   Argument is placed at offset <offset> into the *entire*
   __gnu_c_args_block structure, interpreted as an array of char.
   

The latter change makes it easy to implement runtime functions for
access, since these do not have to take the size of the
`struct_value_block' into account (which may or may not be present),
this is computed once and for all by the compiler.


** Runtime support      

The new runtime functions can be moddeled very close to the present,
only the `offset' parameter used must somehow distinguish between
register offset and stack offsets (perhaps by making it positive vs
negative).

Further more, I suggest we make some faster macros, for iterating over
the entire set of registers.


** Availability

I have implemented this, with some new runtime functions and changes
to gcc as needed.  It is available from

  `iesd.auc.dk:/pub/ObjC/sendv-patch.tar.z' 
                                                                               
But this does not include emulation of next's marg_.. macros, only the
simple one used to iterate over the arguments, given a layout
descriptor and a __gnu_c_args_block.  See (sendmsg.c:objc_msg_sendv)
for an example of use.

/Kresten




From 
Return-Path: krab@iesd.auc.dk
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA18371; Wed, 23 Jun 93 12:58:35 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA23054; Wed, 23 Jun 93 12:58:29 -0400
Received: from iesd.auc.dk by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA05846@wookumz.gnu.ai.mit.edu>; Wed, 23 Jun 93 12:11:57 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA01372
  (5.65c8/IDA-1.5/MD for <gnu-objc@gnu.ai.mit.edu>); Wed, 23 Jun 1993 18:09:42 +0200
Received: by xiv.iesd.auc.dk id AA12386
  (5.65c8/IDA-CLIENT/MD); Wed, 23 Jun 1993 18:10:27 +0200
Message-Id: <199306231610.AA12386@xiv.iesd.auc.dk>
In-Reply-To: <9306222018.AA18238@mobius.geom.umn.edu> (burchard@geom.umn.edu)
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: burchard@geom.umn.edu
Cc: krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
Subject: Re: A portable marg_.. replacement
Date: Wed, 23 Jun 1993 18:10:27 +0200


   Are you planning to add extended versions of the -forward:: and  
   -performv:: messages that allow portable return of arbitrary types?   

This will be the next step.  It will most definitively be supported,
since it will be needed (at least for <wordsize types) to make
distributed objects work transparently.  However, when this will
happen I would rather not say anything about.

Since I wrote that letter to the list I have also added support for
structs passed by invisible reference, which should finish the suite
of functions manipulating arg frames. (I also added imitations of the
NeXT marg_.. macros) The patches will be released in a few weeks with
some other changes before I go for summer vacation.

   I was imagining this would be something like

   - forward:(SEL)aSel :(arglist_t)argFrame withReturn:(void *)rtnPtr;

   Is something like this in the works?

The declared type of -forward:: should have been:

   - (retval_t) forward: (SEL)aSet :(arglist_t)argFrame

Which reflects, that the returntype of this is a special value (as
hairy as the __gnu_c_arg_block) which is used to handle arbitrary
return values.  The primitives to handle it is done, but can currenly
only be used with the return value of __builtin_apply(), so I need to
invent additional machinery for manipulating `retval_t's as is
implemented for argument lists.

/Kresten

From 
Return-Path: krab@iesd.auc.dk
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/y) id AA28951; Wed, 23 Jun 93 18:00:55 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/y) id AA24544; Wed, 23 Jun 93 18:00:48 -0400
Received: from iesd.auc.dk by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA08882@wookumz.gnu.ai.mit.edu>; Wed, 23 Jun 93 17:27:13 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA04691
  (5.65c8/IDA-1.5/MD for <gnu-objc@gnu.ai.mit.edu>); Wed, 23 Jun 1993 23:24:58 +0200
Received: by xiv.iesd.auc.dk id AA14485
  (5.65c8/IDA-CLIENT/MD for gnu-objc@gnu.ai.mit.edu); Wed, 23 Jun 1993 23:25:43 +0200
Message-Id: <199306232125.AA14485@xiv.iesd.auc.dk>
From: Kresten Krab Thorup <krab@iesd.auc.dk>
To: gnu-objc@gnu.ai.mit.edu
Subject: Thanks!
Date: Wed, 23 Jun 1993 23:25:43 +0200


I just felt like thanking all you who have contributed to this
project.  

Thanks for the bug reports, comments and fixes you have sent me.  I
have a pile of comments which seem to grow all the time...  I hope you
understand that I will not always have time for answering every
letter.  I have work to do next to this.  If you send me something
important, but get no answer, please send it again... I might have
missed it.

I often get letters thanking me and encuraging my work.  I am very
grateful for this, it really makes it worth the effort I put into it.
I can have no better reward than your recognition.  I'm just happy
that someone can actually use what I do.

Thanks to everyone who have put consideration into my (sometimes) far
out ideas.  I deliberately use this list as a test bed for ideas,
which I have not alwas put a lot of consideration into.  Please
continue all these well considered answers and discussions.  

During the last month I have been somewhat quiet here, since I've been
going to exams and since I have only been allowed to supply fixes to
gcc.  gcc has been fixed now (by release 2.4.5), so I can start making
changes.  Hopefully I can get some work done in the next few weeks
before my vacation.

Kresten

From 
Return-Path: gdb0@Lehigh.EDU
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA00940; Tue, 29 Jun 93 22:15:51 -0400
Received: from wookumz.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA22828; Tue, 29 Jun 93 22:15:43 -0400
Received: from ns2.CC.Lehigh.EDU by wookumz.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA09191@wookumz.gnu.ai.mit.edu>; Tue, 29 Jun 93 17:57:41 -0400
Received: by ns2.CC.Lehigh.EDU id AA34529
  (5.65c/IDA-1.4.4 for gnu-objc@gnu.ai.mit.edu); Tue, 29 Jun 1993 17:17:46 -0400
Message-Id: <199306292117.AA34529@ns2.CC.Lehigh.EDU>
From: gdb0@Lehigh.EDU (GLENN BLANK)
To: gnu-objc@gnu.ai.mit.edu
Subject: Michael Uhlenberg's class hierarchy
Date: Tue, 29 Jun 1993 17:17:45 EDT

About six months ago, Michael Uhlenberg posted a class hierarchy modeled
on Brad Cox's work.  Since I currently use Stepstone and not the NeXT
variant, I was interested, got it, but didn't have time to get it working.
My first question: has anyone else tried to use this library, and if so
what did you think?  Did it compile?  How reliable is it?  How does it
compare to the Stepstone or the Gnu class library in progress?  (I am
little concerned that the gnu library appears to be developing monolithically.)

Now we have gcc 2.4.5, and I've discovered that his library included
header files that no longer seem to exist.  (The version I have was for
version 2.3.3.)  Is there a more recent version?  (My attempt to mail
M.U. directly bounced.)  If not, perhaps someone can help me figure out
what header files correspond to he ones he included, but now cannot find:
	tconfig.h
	gstdarg.h
	gstddef.h
	objc-proto.h

Thanks!
	    
From 
Return-Path: rogers@magi.ncsl.nist.gov
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA22361; Thu, 19 Aug 93 09:18:54 -0400
Received: from MAGI.NCSL.NIST.GOV by cayuga.cs.rochester.edu (5.61/z) id AA01766; Thu, 19 Aug 93 09:18:44 -0400
Received: by magi.ncsl.nist.gov (4.1/NIST-dsys)
	id AA13211; Thu, 19 Aug 93 09:17:48 EDT
Organization: National Institute of Standards and Technology
	formerly National Bureau of Standards
Date: Thu, 19 Aug 93 9:17:46 EDT
From: Willie Rogers (301) 975-3987 <rogers@magi.ncsl.nist.gov>
To: mccallum@cs.rochester.edu
Subject: Re: Anyone seen a later version of libcoll than 930531
In-Reply-To: Your message of Wed, 18 Aug 93 10:27:52 -0400
Message-Id: <CMM.0.90.2.745766266.rogers@magi.ncsl.nist.gov>

I think your collection library is great.  The only extension I would
like is class support for the C double (real) type.  Can I add a
double member to the elt union (in elt.h) and recompile the library or
is there more to it than that.

Will Rogers
NIST
rogers@magi.ncsl.nist.gov

From 
Return-Path: zazula@pri.com
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA22647; Thu, 19 Aug 93 09:26:53 -0400
Received: from amethyst.math.arizona.edu by cayuga.cs.rochester.edu (5.61/z) id AA01801; Thu, 19 Aug 93 09:26:39 -0400
Received: from sahuarita.math.arizona.edu by amethyst.math.arizona.edu; Thu, 19 Aug 93 06:26:42 -0700
Received: by sahuarita.math.arizona.edu; Thu, 19 Aug 93 06:26:38 MST
Received: by bonehead. (NX5.67c/NX3.0aM)
	id AA01134; Thu, 19 Aug 93 06:18:03 -0700
Date: Thu, 19 Aug 93 06:18:03 -0700
From: Ralph Zazula <zazula@pri.com>
Message-Id: <9308191318.AA01134@bonehead.>
Organization: Pinnacle Research, Inc
Location: The Summit <602/529-1135, 602/529-0117fax>
Received: 
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: <mccallum@cs.rochester.edu>
Subject: Re: Anyone seen a later version of libcoll than 930531


Hi -

I checked out your libcoll stuff but wasn't able to use it since it wouldn't compile  
under stock NEXTSTEP 3.0 or 3.1.

In general, I thought the stuff looked good.  One thing we did in our implementation is  
to place the object type methods in categories of the classes.  This makes it possible  
to link in only the "standard" version of the class, or, extend it to be object-aware by  
linking in the category.

Our List collection was derived by adding a category to NeXT's List object to add the  
methods we needed to conform to our collection protocol(s).

I'd be interested (and will be watching for) any updates to your libcoll, but if it won't  
compile under NEXTSTEP, we can't make use of it...

Ralph
---
Ralph Zazula
President
Pinnacle Research, Inc.
THE NEXTSTEP UTILITY LAB
zazula@pri.com
voice: (602)529-1135
fax:   (602)529-0117 / (602)299-9133

From 
Return-Path:    
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: public class hashtable
Date: Thu, 19 Aug 93 13:22:37 -0400
From: mccallum@cs.rochester.edu

Hi Kresten,

Here's a suggested change for the next version of the runtime:

Make the class hashtable public (in class.c:31)
	static cache_ptr __objc_class_hash = 0;

Remove the "static", and declare the var "extern" in objc-api.h, and
perhaps change it's name a bit (removing the underscores in front).

We should probably do the same with the selector hash tables too.

On of my apps needs to get a list of all the classes in the
executable.  Furthermore NeXT's class and selector hash tables are
public.

Andrew

From 
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Re: public class hashtable 
In-reply-to: Your message of "Fri, 20 Aug 93 09:50:25 +0200."
             <199308200750.AA09399@xiv.iesd.auc.dk> 
Date: Fri, 20 Aug 93 10:00:37 -0400
From: mccallum@cs.rochester.edu

Hi Kresten,

Yup, it sounds good.  This will also let us change the underlying
hashtable implementation without changing the api.  Good idea.

Kresten Krab Thorup <krab@iesd.auc.dk> wrote:
> 
>    Here's a suggested change for the next version of the runtime:
> 	[...]
>    On of my apps needs to get a list of all the classes in the
>    executable.  Furthermore NeXT's class and selector hash tables are
>    public.
> 
> I think we should make an interface for it, say "Class*
> objc_first_class (&iter)" and then "Class* objc_get_next_class
> (&iter)" to iterate...  Giving them the class table directly is too
> nasty -- Besides the table keeps classes being posed for as well,
> keyed by classname prefixed by asterix'es until it is unique.
> 
> Ok?
> 
> 

From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA19573; Tue, 24 Aug 93 20:30:52 -0400
Received: from SERV02.SLAC.Stanford.EDU by cayuga.cs.rochester.edu (5.61/z) id AA17491; Tue, 24 Aug 93 20:30:39 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU (PMDF V4.2-12
 #4747) id <01H24R6G0G1S001MVS@SERV02.SLAC.STANFORD.EDU>; Tue,
 24 Aug 1993 17:30:14 PDT
Received: by kaon.SLAC.Stanford.EDU (NX5.67d/NX3.0S) id AA10294; Tue,
 24 Aug 93 17:29:48 -0700
Received: by NeXT.Mailer (1.95.RR)
Received: by NeXT Mailer (1.95.RR)
Date: Tue, 24 Aug 1993 17:29:48 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: List class
To: mccallum@cs.rochester.edu
Reply-To: Paul_Kunz@SLAC.Stanford.EDU
Message-Id: <9308250029.AA10294@kaon.SLAC.Stanford.EDU>
X-Envelope-To: mccallum@cs.rochester.edu
Content-Transfer-Encoding: 7BIT

   In the implementation file for List your wrote
   

/* Change this #define to YES if you want -makeObjectsPerform: and 

   -makeObjectsPerform:with: to access content objects in reverse order.
   This was the default prior to NeXTSTEP 3.0.
   If you want the NeXTSTEP 3.0 behavior, leave the #define as NO. */
#define LIST_REVERSE_ORDER_DEFAULT NO

   We find no change in NeXTSTEP behaviour between NS 2.x and NS 3.x.    
There's also no change in NS 3.1 documentation.   So I find the last sentence  
in the comment a bug and we find it a bug to ship the List class with the  
macro defined as NO.   Or am I missing something?
   

   There was a confused exchange in comp.lang.objective-c on this topic.   I  
thought it was finally clarified that there's been no change in NeXTSTEP  
behaviour.   The only change I know of is that the documentation was fixed  
with NS 2.0 to explicitly say what the behaiour is.
   

   Please let me know what you think about this matter.
   

   

From 
To: Paul_Kunz@SLAC.Stanford.EDU
Subject: Re: List class 
In-reply-to: Your message of "Tue, 24 Aug 93 17:29:48 PDT."
             <9308250029.AA10294@kaon.SLAC.Stanford.EDU> 
Date: Wed, 25 Aug 93 10:03:20 -0400
From: mccallum@cs.rochester.edu

Yup, you are absolutely right.  I added the #define and the comment in
response to someone on the net, but I didn't check it out myself.

I just checked out the behavior of 3.0, and you're right about reverse
order being the default.  The relevant section of List.m now reads:

/* Change this #define to NO if you want -makeObjectsPerform: and 
   -makeObjectsPerform:with: to access content objects in order
   from lower indeces to higher indeces.
   If you want the NeXTSTEP behavior, leave the #define as YES. */
#define LIST_PERFORM_REVERSE_ORDER_DEFAULT YES

Let me know if you think some other fix would be better.

Thanks for the report.
	Andrew

From 
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Archiving a func ptr
Date: Wed, 01 Sep 93 10:20:17 -0400
From: mccallum@cs.rochester.edu

Hi Kresten,

I started thinking about adding archiving to libcoll, and I just
realized I have no idea how to archive the instance variable:

	int (*_comparison_function)(elt,elt);

Any ideas?  It seems like its a big problem.

Andrew

From 
Return-Path: krab@micro
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA05119; Wed, 1 Sep 93 10:37:08 -0400
Received: from micro.iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA22493; Wed, 1 Sep 93 10:36:56 -0400
Received: by micro. (5.0/SMI-SVR4)
	id AA09340; Wed, 1 Sep 93 16:38:11 +0200
Date: Wed, 1 Sep 93 16:38:11 +0200
From: krab@micro (Kresten Krab Thorup)
Message-Id: <9309011438.AA09340@micro.>
To: mccallum@cs.rochester.edu
Subject: Archiving a func ptr
Cc: krab
Content-Length: 448


  I started thinking about adding archiving to libcoll, and I just
  realized I have no idea how to archive the instance variable:
   
	  int (*_comparison_function)(elt,elt);
   
  Any ideas?  It seems like its a big problem.
 

I guess you will have to ommit that, and then add code to -awake which
installs the right on the basis of the element description.

-awake is called for an object when the entire "read_root..." is done.

ok?

Kresten

From 
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Re: Archiving a func ptr 
In-reply-to: Your message of "Wed, 01 Sep 93 16:38:11 +0200."
             <9309011438.AA09340@micro.> 
Date: Wed, 01 Sep 93 11:03:23 -0400
From: mccallum@cs.rochester.edu

Yup, except this won't work when the user has specified their own
custom comparison function---a feature that the current libcoll allows
quite nicely.

BTW, your mailer isn't giving complete Return-Path: and From: lines.
> Return-Path: krab@micro
> Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu
> (5.61/z) id AA0
> 5119; Wed, 1 Sep 93 10:37:08 -0400
> Received: from micro.iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z)
> id AA22493;
>  Wed, 1 Sep 93 10:36:56 -0400
> Received: by micro. (5.0/SMI-SVR4)
>         id AA09340; Wed, 1 Sep 93 16:38:11 +0200
> Date: Wed, 1 Sep 93 16:38:11 +0200
> From: krab@micro (Kresten Krab Thorup)
> Message-Id: <9309011438.AA09340@micro.>
> To: mccallum@cs.rochester.edu
> Subject: Archiving a func ptr
> Cc: krab
> Content-Length: 448


krab@micro (Kresten Krab Thorup) wrote:
> 
>   I started thinking about adding archiving to libcoll, and I just
>   realized I have no idea how to archive the instance variable:
>    
> 	  int (*_comparison_function)(elt,elt);
>    
>   Any ideas?  It seems like its a big problem.
>  
> 
> I guess you will have to ommit that, and then add code to -awake which
> installs the right on the basis of the element description.
> 
> -awake is called for an object when the entire "read_root..." is done.
> 
> ok?
> 
> Kresten

From 
To: "Stephen Peters" <SPETERS@us.oracle.com>
Subject: Re: Collection class documentation... 
In-reply-to: Your message of "Wed, 08 Sep 93 14:12:16 PDT."
             <9309082112.AA24660@oasun1.us.oracle.com> 
Date: Thu, 09 Sep 93 10:26:12 -0400
From: mccallum@cs.rochester.edu

Hi Stephen,

Great!  libcoll really needs some documentation, and it would be a
while before I could get around to it.  I thought that I would end up
having to do all the documentation, but now we could work on it
together.

You should send mail to Kresten Krab Thorup <krab@iesd.auc.dk> asking
if he has finished his scheme for extracting texinfo directly from
comments in objc source.  I think he has some ideas about how objc
documentation should work, and we should keep in sync with his ideas.

Also, if prose you write is going to become part of the official
libcoll documentation, you'll have to sign an official release with
the FSF.  RMS <rms@prep.ai.mit.edu> is the person to contact about
this.

It might be a little early to go full force on documentation, since
the libcoll API is still in a state of flux.  There should be new
release of libcoll "RSN" (ha).

I'd love to see what you have so far.

** I'm very curious to know in what way and to what extent you're
using libcoll.  I've been disappointed with the small amount of
feedback I've gotten on it.  Even if you only have good things to say,
:-), I'd really appreciate hearing some stories about how it's getting
used.  Of course I'd appreciate constructive criticism and suggested
changes even more. **

Regards,
	Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From 
Return-Path: speters@us.oracle.com
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA12168; Thu, 9 Sep 93 15:58:33 -0400
Received: from keymaster.us.oracle.com by cayuga.cs.rochester.edu (5.61/z) id AA06644; Thu, 9 Sep 93 15:58:17 -0400
Received:  from oracle.us.oracle.com by keymaster.oracle.com (5.59.11/37.7)
	id AA10796; Thu, 9 Sep 93 12:58:27 PDT
Received:  from samsun.us.oracle.com by oracle.us.oracle.com (5.59.9/37.7)
	id AA23974; Thu, 9 Sep 93 12:58:25 PDT
Received: by samsun.oracle.com (5.0/SMI-SVR4)
	id AA07155; Thu, 9 Sep 93 12:52:58 PDT
Date: Thu, 9 Sep 93 12:52:58 PDT
From: speters@us.oracle.com (Stephen Peters)
Message-Id: <9309091952.AA07155@samsun.oracle.com>
To: mccallum@cs.rochester.edu
Subject: Re: Collection class documentation...
Content-Length: 4354

>Hi Stephen,

>Great!  libcoll really needs some documentation, and it would be a
>while before I could get around to it.  I thought that I would end up
>having to do all the documentation, but now we could work on it
>together.

Good.  I'm glad to be of some assistance.

>You should send mail to Kresten Krab Thorup <krab@iesd.auc.dk> asking
>if he has finished his scheme for extracting texinfo directly from
>comments in objc source.  I think he has some ideas about how objc
>documentation should work, and we should keep in sync with his ideas.

Sounds good.  I have some minor ideas about how to structure a texinfo
document, but his ideas might be better formed than mine.  I'll send
him a note.

>Also, if prose you write is going to become part of the official
>libcoll documentation, you'll have to sign an official release with
>the FSF.  RMS <rms@prep.ai.mit.edu> is the person to contact about
>this.

Will do.

>It might be a little early to go full force on documentation, since
>the libcoll API is still in a state of flux.  There should be new
>release of libcoll "RSN" (ha).

Understood completely.  I'm working on documenting things partially
for my own use right now (it's a good way for me to figure out what
all the different shallowCopy methods do, for example), but I realize
that some of it might have to be reworked with the next release of
libcoll.  Any idea of how S RSN is? :-)

>I'd love to see what you have so far.

I'm still fleshing things out, but I'll get a copy to you when I've
got a little more.  Currently, I've been thinking that documenting
the protocols is a good way to go -- thus providing a "overall" view,
and then using class descriptions to flesh out some of the more
implementation-dependent portions and to focus on subclass
responsibilities.  I worry that this will just expand the material,
however, and not make it easier to understand.  Any thoughts?  I'll
ask Kresten what he's thinking in terms of objc documentation also...

>** I'm very curious to know in what way and to what extent you're
>using libcoll.  I've been disappointed with the small amount of
>feedback I've gotten on it.  Even if you only have good things to say,
>:-), I'd really appreciate hearing some stories about how it's getting
>used.  Of course I'd appreciate constructive criticism and suggested
>changes even more. **

Well, I haven't found much not to like, and I've found a *lot* of
really nice ideas -- the DelegateList class being one of them.  Is
this borrowed from Smalltalk?  I really like it...

What is the current status of the String class/hierarchy?  That's
something I'd like to hear some more information about (I could only
find a reference in the DISCUSSION file about it being worked on, and
I have only just joined the gnu-objc mailing list).

One minor question: Is there any reason you #define things like
FOR_LINKLIST() or GNU_ADDRESS() in the public .h file, rather than in
the .m file itself?  Unless you're anxious to have generic subclasses
be able to use these "low-level" interfaces (which I would frown on,
as I think it destroys some encapsulation), I would advocate moving
them into the implementation file.  Of course, things like
GNU_NOT_IN_LIST and COLL_NO_OBJECT would have to stay in the interface
file, at least until another solution through either exception
handling or a "Nil" object is implemented.

Are you accepting notes on porting changes yet?  I had to make a few
small modifications to get it working on my Solaris 2.2 machine.  I'd
been assuming that you're waiting to get it in a more stable form
first, but if you're interested I can send them to you.

I've been thinking that adding 
   - firstObject: (void **)enumState
   - getFirstElement: (elt *)anElementPtr withEnumState: (void **)enumState
methods to the Collecting protocol might make some sense, rather than
call -nextObject: with a pointer to a null pointer.  It may be the
case that a subclass of Collection will want to do a fair amount of
setup before the enumeration, and separating the initial case and the
loop case for the enumeration might be a desirable feature.  This also
puts the burden on the object, not the consumer, to initialize
enumState. (and besides, the Collecting protocol already has 92
methods in it -- what's 2 more? ;-)

Anyway, hope to talk to you again soon!

					Stephen Peters

From 
Return-Path: speters@us.oracle.com
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA12168; Thu, 9 Sep 93 15:58:33 -0400
Received: from keymaster.us.oracle.com by cayuga.cs.rochester.edu (5.61/z) id AA06644; Thu, 9 Sep 93 15:58:17 -0400
Received:  from oracle.us.oracle.com by keymaster.oracle.com (5.59.11/37.7)
	id AA10796; Thu, 9 Sep 93 12:58:27 PDT
Received:  from samsun.us.oracle.com by oracle.us.oracle.com (5.59.9/37.7)
	id AA23974; Thu, 9 Sep 93 12:58:25 PDT
Received: by samsun.oracle.com (5.0/SMI-SVR4)
	id AA07155; Thu, 9 Sep 93 12:52:58 PDT
Date: Thu, 9 Sep 93 12:52:58 PDT
From: speters@us.oracle.com (Stephen Peters)
Message-Id: <9309091952.AA07155@samsun.oracle.com>
To: mccallum@cs.rochester.edu
Subject: Re: Collection class documentation...
Content-Length: 4354

>Hi Stephen,

>Great!  libcoll really needs some documentation, and it would be a
>while before I could get around to it.  I thought that I would end up
>having to do all the documentation, but now we could work on it
>together.

Good.  I'm glad to be of some assistance.

>You should send mail to Kresten Krab Thorup <krab@iesd.auc.dk> asking
>if he has finished his scheme for extracting texinfo directly from
>comments in objc source.  I think he has some ideas about how objc
>documentation should work, and we should keep in sync with his ideas.

Sounds good.  I have some minor ideas about how to structure a texinfo
document, but his ideas might be better formed than mine.  I'll send
him a note.

>Also, if prose you write is going to become part of the official
>libcoll documentation, you'll have to sign an official release with
>the FSF.  RMS <rms@prep.ai.mit.edu> is the person to contact about
>this.

Will do.

>It might be a little early to go full force on documentation, since
>the libcoll API is still in a state of flux.  There should be new
>release of libcoll "RSN" (ha).

Understood completely.  I'm working on documenting things partially
for my own use right now (it's a good way for me to figure out what
all the different shallowCopy methods do, for example), but I realize
that some of it might have to be reworked with the next release of
libcoll.  Any idea of how S RSN is? :-)

>I'd love to see what you have so far.

I'm still fleshing things out, but I'll get a copy to you when I've
got a little more.  Currently, I've been thinking that documenting
the protocols is a good way to go -- thus providing a "overall" view,
and then using class descriptions to flesh out some of the more
implementation-dependent portions and to focus on subclass
responsibilities.  I worry that this will just expand the material,
however, and not make it easier to understand.  Any thoughts?  I'll
ask Kresten what he's thinking in terms of objc documentation also...

>** I'm very curious to know in what way and to what extent you're
>using libcoll.  I've been disappointed with the small amount of
>feedback I've gotten on it.  Even if you only have good things to say,
>:-), I'd really appreciate hearing some stories about how it's getting
>used.  Of course I'd appreciate constructive criticism and suggested
>changes even more. **

Well, I haven't found much not to like, and I've found a *lot* of
really nice ideas -- the DelegateList class being one of them.  Is
this borrowed from Smalltalk?  I really like it...

What is the current status of the String class/hierarchy?  That's
something I'd like to hear some more information about (I could only
find a reference in the DISCUSSION file about it being worked on, and
I have only just joined the gnu-objc mailing list).

One minor question: Is there any reason you #define things like
FOR_LINKLIST() or GNU_ADDRESS() in the public .h file, rather than in
the .m file itself?  Unless you're anxious to have generic subclasses
be able to use these "low-level" interfaces (which I would frown on,
as I think it destroys some encapsulation), I would advocate moving
them into the implementation file.  Of course, things like
GNU_NOT_IN_LIST and COLL_NO_OBJECT would have to stay in the interface
file, at least until another solution through either exception
handling or a "Nil" object is implemented.

Are you accepting notes on porting changes yet?  I had to make a few
small modifications to get it working on my Solaris 2.2 machine.  I'd
been assuming that you're waiting to get it in a more stable form
first, but if you're interested I can send them to you.

I've been thinking that adding 
   - firstObject: (void **)enumState
   - getFirstElement: (elt *)anElementPtr withEnumState: (void **)enumState
methods to the Collecting protocol might make some sense, rather than
call -nextObject: with a pointer to a null pointer.  It may be the
case that a subclass of Collection will want to do a fair amount of
setup before the enumeration, and separating the initial case and the
loop case for the enumeration might be a desirable feature.  This also
puts the burden on the object, not the consumer, to initialize
enumState. (and besides, the Collecting protocol already has 92
methods in it -- what's 2 more? ;-)

Anyway, hope to talk to you again soon!

					Stephen Peters

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA09887; Wed, 15 Sep 93 11:21:20 -0400
Received: from geech.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA09494; Wed, 15 Sep 93 11:20:58 -0400
Received: from iesd.auc.dk by geech.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA06210@geech.gnu.ai.mit.edu>; Wed, 15 Sep 93 05:34:48 -0400
Received: from aton.iesd.auc.dk by iesd.auc.dk with SMTP id AA23640
  (5.65c8/IDA-1.5/MD for <gnu-objc@gnu.ai.mit.edu>); Wed, 15 Sep 1993 11:33:24 +0200
Received: by aton.iesd.auc.dk id AA00398
  (5.65c8/IDA-CLIENT/MD); Wed, 15 Sep 1993 11:33:25 +0200
Date: Wed, 15 Sep 1993 11:33:25 +0200
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309150933.AA00398@aton.iesd.auc.dk>
To: rasmus@dannug.dk
Cc: gnu-objc@gnu.ai.mit.edu
In-Reply-To: <9309080931.AA00624@peter.dannug.dk> (rasmus@dannug.dk)
Subject: Re: Making ObjC more flexible 


   Seldomly, more flexibility of ObjC dynamic binding has been asked  
   for.  

It is because people are not used to such flexibility.  I agree that
it would be great to have more flexibility in terms of programmers
controlling the method dispatch, but it is important to keep objc
simple.  The simplicity is the power of objc, so lets not clutter it
up as someone has already done to other languages. (notch, notch)

   I'd love to see *user costumizable* message dispatch in ObjC ...
   Such Meta-programming would enable us possibilities as:

	   - encapsulators (trickers, monitors, pre/post conditions ..)
	   - pre/post condition checking
	   - new debugging tools (statistic/sequence of msg sending ...)

I think that the way to go is to come up with a good mechanism for
encapsulating in such a way that all messages to "self" are cought as
well.  (solution sketched below)

   I can think of two ways to achieve *user costumizable* message  
   dispatch

   1) At a per runtime basis: (objc_msgSend as function pointer)

Possible, but would require the entire code to be recompiled when
changing runtime.  That would be cause of a *lot* of trouble.

   2) At a per object basis: (add extra meta* to all objs)

This would have an overhead of one word per object, and be
invompatible with a lot existing code.

A good solution to this problem has already been developed by some
folks at my C.S. department.  This solution also has the "pay if you
play" property.  I will tell more about it in a following posting
under some other subject.

Kresten




  

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA06623; Wed, 15 Sep 93 09:58:56 -0400
Received: from geech.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA08925; Wed, 15 Sep 93 09:58:41 -0400
Received: from iesd.auc.dk by geech.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA06223@geech.gnu.ai.mit.edu>; Wed, 15 Sep 93 05:41:06 -0400
Received: from aton.iesd.auc.dk by iesd.auc.dk with SMTP id AA23718
  (5.65c8/IDA-1.5/MD); Wed, 15 Sep 1993 11:39:19 +0200
Received: by aton.iesd.auc.dk id AA00443
  (5.65c8/IDA-CLIENT/MD); Wed, 15 Sep 1993 11:39:19 +0200
Date: Wed, 15 Sep 1993 11:39:19 +0200
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309150939.AA00443@aton.iesd.auc.dk>
To: rms@gnu.ai.mit.edu
Cc: alexk@research.otc.com.au, schuller@dutiws.twi.tudelft.nl,
        gnu-objc@gnu.ai.mit.edu
In-Reply-To: <9309101151.AA24784@mole.gnu.ai.mit.edu> (rms@gnu.ai.mit.edu)
Subject: Re: dld and ObjC? 


       The main problem is with dld, some symbols which have been resolved
       are later marked as unresolved and the object file is not loaded 
       properly.  

       Feel like writing a new dynamic loader ?

   If dld has a problem, the first thing to do is to investigate the
   problem and try to fix it.  To assume it needs to be entirely replaced
   is premature.  Any program can have a bug.

dld has some general problems and "non generic" solutions.  It should
definitively be rewritten using bfd.  This is a major task.

Kresten


From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA02750; Wed, 15 Sep 93 08:15:48 -0400
Received: from geech.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA08412; Wed, 15 Sep 93 08:15:31 -0400
Received: from iesd.auc.dk by geech.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA06753@geech.gnu.ai.mit.edu>; Wed, 15 Sep 93 07:15:53 -0400
Received: from aton.iesd.auc.dk by iesd.auc.dk with SMTP id AA25255
  (5.65c8/IDA-1.5/MD for <gnu-objc@gnu.ai.mit.edu>); Wed, 15 Sep 1993 13:14:30 +0200
Received: by aton.iesd.auc.dk id AA01183
  (5.65c8/IDA-CLIENT/MD); Wed, 15 Sep 1993 13:14:30 +0200
Date: Wed, 15 Sep 1993 13:14:30 +0200
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309151114.AA01183@aton.iesd.auc.dk>
To: speters@us.oracle.com
In-Reply-To: <9309092011.AA07190@samsun.oracle.com> (speters@us.oracle.com)
Subject: Re: Collection class documentation...
Cc: krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu


[ The following is of general interest to people writing and documenting 
  ObjC code.  Please read carefully and comment - Kresten ]

   He suggested that I talk to you, both to inquire on your scheme for
   extracting Texinfo from ObjC source code, but also because he thought
   you had some ideas on the way objc documentation should work.

   I'd be interested in hearing any ideas you do have, since both libcoll
   and my documentation are in a state of flux :-)  It's probably best to
   iron out such formatting & structuring considerations now.

My idea is to make it as simple as possible, still enabling automatic
transformations of the code/docs.  The GNU Coding Standards says that
declarations/definitions should be prepended by a short explanatory
text.  To make it simple and standard I will stick to this.  The
standards also disapproves the comments to individual arguments to
functions, so the scheme is very simple: Prepend any declaration or
definition with a comment describing it.

That basic scheme is extended to ease automatic manipulation.  The
manipulation is done with a handwritten parser/preprocessor which can
extract the documentation from special comments in the original code.
The idea is to extract all the comments and some information from
declarations/definitions to produce a TeXinfo document.

First, the content of all comments should be valid TeXinfo code.
This is easily obtained, since the only special character is "@", so
just put "@@" whenever you want an commercial at sign.  Read the
TeXinfo manual for futher explanation of how to do sectioning, text
fonts and other effects.

Secondly, a explanatory comment may be handled especially if it starts
with some specific symbol(s).  That is we define a set of new "escape"
characters that may affect formatting etc in the resulting text.

The first special character is the "TeXinfo escape" which I use for
"verbatim" TeXinfo.  That is

  //@ This is verbatim TeXinfo code
  //  which is simply passed through the objc2texi
  //  with the comment marks and the leading "@@" stripped.

Such comments may be used for general text, but also for introducing
chapters, sections or nodes.  E.g.:

  //@ @chapter The @code{Collection} Class
  //  ...
  //

Note: The parser "preprocessor" will also be able to handle other
kinds of comments, like the following or other like it:

   /*@ This is verbatim TeXinfo code 
    *  ...
    *  ...
    */

The next special character is the method character "-".  Method comments
describe a method and its arguments (arguments should be referred as
@var{name-of-var}) as described in the coding standards.  The
objc2texi filter will know the context (e.g. current class) and will
put it in appropriate indices automatically.  An example:


   //- Add @var{newElement} to the receiving collection if it
   //  is not already present.  Returns self.

   - addElementIfAbsent: (elt)newElement
   {
     ...
   }

The objc2texi filter will by itself parse the method head (until the
first "{" or ";" character) and make sure it is typeset as a parahraph
headed by the method name.  This is an example of what the above turns
out as in "info" code:

  @deftypemethod {Collection} {} -addElementIfAbsent: (elt) @var{newElement} 
  Add @var{newElement} to the receiving collection if it
  is not already present.  Returns self.@refill
  @end deftypemethod

And Formatted:

 - Method on Collection:  -addElementIfAbsent: (elt) NEWELEMENT
     Add NEWELEMENT to the receiving collection if it is not already
     present.  Returns self.

Note that the filter automatically determines the Class (and category
if any). 

Next, the variable comment character "$":

  //$ Symbolic constant for the missing element.  
  //  Methods that may return this value will explicitly
  //  state so in their respective documentation.

  const elt COLL_NO_ELEMENT = ((elt)(~0L));

Yields:

 - Variable: const elt COLL_NO_ELEMENT
     Symbolic constant for the missing element.  Methods that may
     return this value will explicitly state so in their respective
     documentation.

The filter will itself parse the following variable declaration and
put the variable name in indices.

Finally the function comment character "!".  This is like methods, the
filter will parse the definition/declaration head and register
appropriate informatiuon in indices.  Please remember not to put
comments on individual arguments. Thus:

  /*! This is a silly function returns BLAH. */
  int a_function (int x, /* does this */
	          char y /* does that */)

Is not good -- the comments on the arguments are lost.  This, you
should write as:

  /*! This is a silly function taking two arguments:
   *  @var{x} which does this, and @var{y} doing that.
   *  The function returns BLAH. */
  int a_function (int x, char y)

That is far simpler for a filter to manipulate.  Remeber to write it
as *full sentences*.  That will make the resulting text much more
pleasant to read.  I know I am far from perfect in english, especially
in punctuation but I am sure people will help me with that.


   Is there a preliminary doc for GNU Objective-C that I can look at?
   For example, one that describes the Object class in all its glory?

I have a very preliminary doc for an old version of the "Collection"
class of libcoll which I can send you if you'd like.

The objc2texi filter is not finished, but I guess that is no problem
when the scheme is as simple as described above.  I have a few days
"in vaccum" waiting for my working visa to arrive, so I will see if I
can do a preliminary implementation now.  

Kresten

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA07355; Wed, 15 Sep 93 10:16:25 -0400
Received: from mole.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA09044; Wed, 15 Sep 93 10:16:09 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA14216@mole.gnu.ai.mit.edu>; Wed, 15 Sep 93 09:22:40 -0400
Date: Wed, 15 Sep 93 09:22:40 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9309151322.AA14216@mole.gnu.ai.mit.edu>
To: krab@iesd.auc.dk
Cc: speters@us.oracle.com, krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
In-Reply-To: <199309151114.AA01183@aton.iesd.auc.dk> (message from Kresten Krab Thorup on Wed, 15 Sep 1993 13:14:30 +0200)
Subject: Re: Collection class documentation...

Programmers often write documentation for a library in the form of a
catalogue the functions, saying what each function does.

A good manual is organized in a completely different fashion: by tasks
that the user might have in mind, and how to accomplish them.  A
catalogue of functions and their meanings is the wrong approach.
Regardless of how well it is written, it cannot do the job.  The fact
that many programmers think that a catalogue of functions is
reasonable documentation is one of the problems that the GNU project
has to cope with again and again.

Conventions for putting Texinfo text into comments in a C source file
cannot be useful for anything except a catalogue of functions.  They
are no help in writing a proper manual.  So these conventions are no
help to the job we should really be trying to do.

Meanwhile, to state such convention would reinforce the widespread
view that a catalogue of functions is a satisfactory form of
documentation.  This would be counterproductive.  We need to teach
people exactly the opposite of that.

For this reason, it would be a mistake to endorse conventions for
putting Texinfo into comments in source files for documentation.

There is another purpose for which Texinfoizing source files could
make sense.  This is for "literate programming"--the technique, used
in TeX, whereby the comments and the code can print out as a book.
Not a book about how to *use* the library, but a book describing its
implementation.

If you are a real wizard, and prepared to do a fair amount of work,
contact me, and I can talk to you about finishing up the literate
programming tool I started writing a year ago.


From 
Return-Path: tuparev@EMBL-Heidelberg.DE
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA10969; Wed, 15 Sep 93 11:47:41 -0400
Received: from geech.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA09661; Wed, 15 Sep 93 11:47:23 -0400
Received: from monk.NMR.EMBL-Heidelberg.DE by geech.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA08273@geech.gnu.ai.mit.edu>; Wed, 15 Sep 93 10:36:25 -0400
Received: from miles by NMR.EMBL-Heidelberg.DE (NX5.67c/NX3.0M)
	id AA27948; Wed, 15 Sep 93 16:31:18 +0200
From: Georg Tuparev <tuparev@EMBL-Heidelberg.DE>
Message-Id: <9309151431.AA27948@NMR.EMBL-Heidelberg.DE>
Received: by miles.NMR.EMBL-Heidelberg.DE (NX5.67d/NX3.0X)
	id AA16120; Wed, 15 Sep 93 16:30:06 +0200
Date: Wed, 15 Sep 93 16:30:06 +0200
Received: by NeXT.Mailer (1.95)
Received: by NeXT Mailer (1.95)
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Collection class documentation...
Cc: gnu-objc@gnu.ai.mit.edu

Richard,

> A good manual is organized in a completely different fashion: by tasks
> that the user might have in mind, and how to accomplish them.  A
> catalogue of functions and their meanings is the wrong approach.
> Regardless of how well it is written, it cannot do the job.  The fact
> that many programmers think that a catalogue of functions is
> reasonable documentation is one of the problems that the GNU project
> has to cope with again and again.
> 


I fully area with one extension: every GOOD manual has to have a reference  
manual for the gurus. I think NeXT is on the right track with their manuals  
(they are far to be perfect, but may be they are the best I know). A catalogue  
of functions/methods could be part of this reference manual.
> .......
> There is another purpose for which Texinfoizing source files could
> make sense.  This is for "literate programming"--the technique, used
> in TeX, whereby the comments and the code can print out as a book.
> Not a book about how to *use* the library, but a book describing its
> implementation.
> 

> If you are a real wizard, and prepared to do a fair amount of work,
> contact me, and I can talk to you about finishing up the literate
> programming tool I started writing a year ago.

Working on the HyperKnowledge project sci-tools@embl-heidelberg.de we start  
thinking about the same problem two or three months ago. We want to go one step  
further, and to create a method for writing a living books, but unfortunately,  
that's a long term dream. First step is to make a nice documentation for our  
source. So, we can do some work together (I know several students from the  
University of Heidelberg, playing and loving GNU). If any interest on the  
subject, please contact me.

-- georg --
Georg Tuparev
EMBL / Protein Design
Meyerhofstr. 1
D-69117 Heidelberg
Germany
tuparev@embl-heidelberg.de (NeXT-mail)

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA18889; Wed, 15 Sep 93 15:21:17 -0400
Received: from mole.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA11194; Wed, 15 Sep 93 15:21:00 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA14996@mole.gnu.ai.mit.edu>; Wed, 15 Sep 93 14:24:06 -0400
Date: Wed, 15 Sep 93 14:24:06 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9309151824.AA14996@mole.gnu.ai.mit.edu>
To: tuparev@EMBL-Heidelberg.DE
Cc: gnu-objc@gnu.ai.mit.edu
In-Reply-To: <9309151431.AA27948@NMR.EMBL-Heidelberg.DE> (message from Georg Tuparev on Wed, 15 Sep 93 16:30:06 +0200)
Subject: Re: Collection class documentation...

A good manual does not need a separate catalogue of functions.
If you use the standard Texinfo constructs, you get an index
which lists all the functions.  This makes it easy, using Info,
to find any particular function.

An additional section, documenting functions one by one,
would be superfluous.

I know whereof I speak.  I have written all or part of several
GNU manuals, and people think I'm pretty good at it.
Please believe me.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA17484; Wed, 15 Sep 93 14:39:01 -0400
Received: from mole.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA10920; Wed, 15 Sep 93 14:38:43 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA15032@mole.gnu.ai.mit.edu>; Wed, 15 Sep 93 14:35:47 -0400
Date: Wed, 15 Sep 93 14:35:47 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9309151835.AA15032@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
Cc: gnu-objc@gnu.ai.mit.edu
In-Reply-To: <9309151453.AA08880@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: Collection class documentation... 

    I agree that we should have overview documentation organized by tasks,
    but I think a class reference manual in the form of an alphabetical
    list of methods for a class is useful too.

If you look at a GNU manual, such as the GNU Library manual, which
documents a lot of functions, I think you'll find that (1) an
additional catalogue of functions would not really add much, and (2)
it would add a hundred or more pages to the size of the manual.  All
in all, it would make the manual worse, not better.

It is very disturbing to see so many people ready to charge
down a tempting dead end.  Please don't encourage this.

From 
Return-Path: liberte@ncsa.uiuc.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA21385; Wed, 15 Sep 93 16:29:56 -0400
Received: from geech.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA11681; Wed, 15 Sep 93 16:29:40 -0400
Received: from newton.ncsa.uiuc.edu by geech.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA11243@geech.gnu.ai.mit.edu>; Wed, 15 Sep 93 15:28:40 -0400
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03664
  (5.65a/IDA-1.4.2 for gnu-objc@gnu.ai.mit.edu); Wed, 15 Sep 93 14:27:12 -0500
Return-Path: <liberte@ncsa.uiuc.edu>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
	id AA12295; Wed, 15 Sep 93 14:26:06 CDT
Date: Wed, 15 Sep 93 14:26:06 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9309151926.AA12295@void.ncsa.uiuc.edu>
To: gnu-objc@gnu.ai.mit.edu
Subject: Re: documentation

Having been an editor and user of the Emacs Lisp reference manual, I
can concur with RMS. An alphabetized ordering of descriptions is the
wrong way to go about things; only indexes should be alphabetized.

Also as a NeXT programmer, I found the NeXT documentation to be lacking
exactly where methods were simply listed.  How the methods may
be used with other methods, and the patterns of those uses are what the
programmer needs to find out, not how they are spelled.  The NeXT
concept chapters are the right idea, and the intro material at the
start of each class helped, but they are not quite enough.  There is much
that is left unsaid.

But I can see automatic extraction of documentation from source as being
useful for programmers and implementors if it can be suitably structured.  
There should probably be documentation external to the source that
references source doc fragments.  Otherwise, the source would grow
unwieldy.

Dan LaLiberte
National Center for Supercomputing Applications

liberte@ncsa.uiuc.edu
(Fight interface copyrights and software patents.
 Join the League for Programming Freedom: lpf@uunet.uu.net)

From 
Return-Path: amanda@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA06961; Thu, 16 Sep 93 00:45:05 -0400
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA13519; Thu, 16 Sep 93 00:44:49 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA28388@albert.gnu.ai.mit.edu>; Thu, 16 Sep 93 00:03:07 -0400
Received: from iesd.auc.dk by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA19394; Thu, 16 Sep 93 00:02:46 EDT
Received: from red.iesd.auc.dk by iesd.auc.dk with SMTP id AA08156
  (5.65c8/IDA-1.5/MD for <gnu-objc@prep.ai.mit.edu>); Thu, 16 Sep 1993 06:02:31 +0200
Received: by red.iesd.auc.dk id AA15872
  (5.65c8/IDA-CLIENT/MD); Thu, 16 Sep 1993 06:02:34 +0200
Date: Thu, 16 Sep 1993 06:02:34 +0200
From: Per Abrahamsen <amanda@iesd.auc.dk>
Message-Id: <199309160402.AA15872@red.iesd.auc.dk>
To: gnu-objc@prep.ai.mit.edu
Subject: Documentation


I have written a manual for a C library in the format advocated by
RMS, i.e. organized by topic with text explaining the higher level
design and the interactions between the functions.

When writing the manual, I found it very useful to have the
descriptions of the individual functions in a separate file.  This
allowed me to concentrate on the higher level description without
worrying about the details of the individual functions.  I simply
inserted a macro like ``@fundesc{matrix_create}'' at the place in the
text where I wanted the description of an individual function to be
appear, and had a tool to expand those macros.

Of course having the function documentation available in a structured
format also allowed me to automatically create a set of man pages.
Some people claim they prefer that format, and I have no reason to
think they are lying.

Kresten Krab's suggestion has the additional advantage that the
documentation is located close to the code, thus increasing the chance
that the documentation will be somewhat related to the code.  So I
think the //-, //$, and //! comments would be very useful.  I don't
see the use for //@ comments, though.

From 
Return-Path: dkk@mit.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA28081; Thu, 16 Sep 93 12:14:45 -0400
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA16090; Thu, 16 Sep 93 12:14:29 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA09416@albert.gnu.ai.mit.edu>; Thu, 16 Sep 93 11:06:43 -0400
Received: from MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA04222; Thu, 16 Sep 93 11:06:30 EDT
Received: from PUTTANESCA.MIT.EDU by MIT.EDU with SMTP
	id AA01596; Thu, 16 Sep 93 11:06:23 EDT
Received: by puttanesca (5.57/4.7) id AA18249; Thu, 16 Sep 93 11:06:22 -0400
Date: Thu, 16 Sep 93 11:06:22 -0400
From: David Krikorian <dkk@mit.edu>
Message-Id: <9309161506.AA18249@puttanesca>
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Documentation
Reply-To: dkk@mit.edu
Home: 47 Lake St., Arlington, MA 02174, (617) 646-9289, -9269 (fax)

I have written a user manual for a GUI-based application.  That manual
had both "using" and "reference" sections.  I still don't think a
class library should have dual explanations like that.

The main reason for a reference section in that manual was that people
used the graphical user interface in two different ways:

	- "I want to do XXXXX.  How do I?"

	- "I'm using the XXXXX dialog box, and wonder what else it
	   lets me do."

Since only a small portion of a dialog box's functionality is used for
a particular task (ie: making a word bold).  The above two user-views
are quite different, in my opinion, and each have their time and place.

I don't see that as relevant to a software library, as long as the
author has gone to lengths to include the explanation for every
reasonable use of a library call *somewhere* in the manual.  If
documenting a whole group of classes, in which many classes are used
together for one class, each of the *classes* would probably need to
be explained separately, but not each *method* within the classes.

Another important part of a manual is a set of examples, which should
be either interspersed with the "how to" text if short, or in their
own section if long (or both).  Code comments aren't relevant here,
either.

In other words, I agree with rms.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA29030; Thu, 16 Sep 93 12:37:24 -0400
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA16217; Thu, 16 Sep 93 12:37:07 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA10119@albert.gnu.ai.mit.edu>; Thu, 16 Sep 93 11:54:29 -0400
Received: from mole.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA06722; Thu, 16 Sep 93 11:54:14 EDT
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA18028@mole.gnu.ai.mit.edu>; Thu, 16 Sep 93 11:53:54 -0400
Date: Thu, 16 Sep 93 11:53:54 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9309161553.AA18028@mole.gnu.ai.mit.edu>
To: amanda@iesd.auc.dk
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199309160402.AA15872@red.iesd.auc.dk> (message from Per Abrahamsen on Thu, 16 Sep 1993 06:02:34 +0200)
Subject: Re: Documentation

    I have written a manual for a C library in the format advocated by
    RMS, i.e. organized by topic with text explaining the higher level
    design and the interactions between the functions.

    When writing the manual, I found it very useful to have the
    descriptions of the individual functions in a separate file.

If this way of keeping the files is convenient for you, there's no
reason you can't use it.  (I think you'd find it inconvenient for a
large manual which describes hundreds of functions.)  What I'm
concerned about is what the text should say--not how it is split into
files.

Individual function descriptions, suitable for stand-alone "man page"
use, are simply not right for inclusion in a good manual.  In a
topic-structured manual, the descriptions of the functions are not
independent.  They have to be written to fit the context.

To make the manual shorter, material that is common to several
functions in one section is stated just once--outside the descriptions
of the individual functions.  So is background information for them.
Then the "descriptions of" these functions should (for brevity's sake)
not mention this information at all.  To do this, you need to write
the whole section as a unit.  It does not work to write individual
function descriptions separately.

To use the same text both for a proper manual and for a catalogue of
functions is thus not a workable idea.  It can't be done.  You can
*try* to do it--but the result will be text suitable for a catalogue
of functions, and not suitable for a proper manual.

As for having man pages as well as a proper manual, this is not
necessary.  We need to provide a convenient way to ask "how do I use
function foo"--but Info makes it possible to use the manual for this.
So there's no need for separate man pages.

For these reasons, having a separate file for each function's
description doesn't have the benefits one might have hoped for.  It is
probably better to keep the whole text of one section contiguous, so
you can more easily edit it all at once.  But this is not crucial.
 
What is crucial is that the GNU project will not adopt standards that
give people the wrong idea about what is good documentation!  We may
not always be able to get good documentation, but we MUST show people
clearly what they should AIM for.

From 
Return-Path: speters@us.oracle.com
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA18495; Thu, 16 Sep 93 20:29:39 -0400
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA18522; Thu, 16 Sep 93 20:29:22 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA17564@albert.gnu.ai.mit.edu>; Thu, 16 Sep 93 19:39:45 -0400
Received: from gatekeeper.oracle.com by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA29287; Thu, 16 Sep 93 19:39:37 EDT
Received:  from oracle.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7)
	id AA13887; Thu, 16 Sep 93 16:39:24 PDT
Received:  from samsun.us.oracle.com by oracle.us.oracle.com (5.59.9/37.7)
	id AA21780; Thu, 16 Sep 93 16:39:20 PDT
Received: by samsun.oracle.com (5.0/SMI-SVR4)
	id AA22104; Thu, 16 Sep 93 16:33:47 PDT
Date: Thu, 16 Sep 93 16:33:47 PDT
From: speters@us.oracle.com (Stephen Peters)
Message-Id: <9309162333.AA22104@samsun.oracle.com>
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Documentation
Content-Length: 1972


I've been following this thread with some interest, mostly because it
was my offer to Andrew McCallum (expressing interest in helping with
the Collection library doc) which served to touch off this entire
debate. :-)

To my mind, RMS has brought up a very good point -- if we try to
structure the manual around TeXinfo extracted from source, what we end
up with will most likely be unwieldy for the person who just wants to
find out how to create a queue using the Collection objects.
Providing a complete manual by topic is better for the person who
wants to *use* the objects.

That doesn't mean that I don't think embedding *some* documentation
into the source is a bad idea.  In fact, I'm in favor of it.  It will
serve very well as a way to provide a "Reference" manual (or perhaps a
Referece section to the main manual), and in addition (as Greg Franks
noted), it provides an easy way for a class browser to call up
documentation on the methods of a class on the fly.

In many ways, however, I think documentation that is so closely linked
with the code is best used as a way for the programmer to describe how
a function or method works, rather than how it might be used.  To this
end, it might make sense to use the TeXinfo'd source to create a
separate "Programmer's Reference" manual, which would be little more
than a catalog of class methods, but would comment more on the
implementation details than on the "big picture".

rms@gnu.ai.mit.edu (Richard Stallman) wrote:
>What is crucial is that the GNU project will not adopt standards that
>give people the wrong idea about what is good documentation!  We may
>not always be able to get good documentation, but we MUST show people
>clearly what they should AIM for.

I can't agree with this statement more.  Overall, I've found the GNU
info docs to be of very good quality -- often better than what I can
find commercially.  The Objective-C docs should certainly make a
strong attempt to mirror this quality.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA27837; Fri, 17 Sep 93 00:08:19 -0400
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA19259; Fri, 17 Sep 93 00:08:02 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA20441@albert.gnu.ai.mit.edu>; Thu, 16 Sep 93 23:30:09 -0400
Received: from mole.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA08419; Thu, 16 Sep 93 23:29:40 EDT
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA20458@mole.gnu.ai.mit.edu>; Thu, 16 Sep 93 23:29:23 -0400
Date: Thu, 16 Sep 93 23:29:23 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9309170329.AA20458@mole.gnu.ai.mit.edu>
To: speters@us.oracle.com
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <9309162333.AA22104@samsun.oracle.com> (speters@us.oracle.com)
Subject: Re: Documentation

    It will serve very well as a way to provide a "Reference" manual
    (or perhaps a Referece section to the main manual)

There's no room in a well-written manuals for a separate "reference
section" which is a catalogue of functions.  I mean literally no
room--this would probably add 50% to the size of the manual.

There is also no need for them.  The sections that describe the
functions for learning purposes also serve for reference.  Look at the
C Library manual or the Emacs Lisp manual and you'll see.  There are
no duplicate "reference sections", but that's no lack.

With suitable Info node structuring, the manual can also be convenient
for browsing.

The idea of a catalogue of functions seems very natural to a
programmer.  It is so natural *to implement* that many programmers
feel sure it must be good for something.  But it isn't.

Precisely because it is so natural to write a catalogue of functions
and think you have written a manual, we need to avoid steps that would
encourage that belief.

From 
Return-Path: billb@ripley.sunquest.com
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA00465; Fri, 17 Sep 93 16:18:32 -0400
Received: from albert.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/z) id AA23606; Fri, 17 Sep 93 16:18:13 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA05257@albert.gnu.ai.mit.edu>; Fri, 17 Sep 93 13:26:27 -0400
Received: from aeneas.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA01368; Fri, 17 Sep 93 13:26:16 EDT
Received: by aeneas.MIT.EDU (5.57/4.7) id AA22221; Fri, 17 Sep 93 13:25:21 -0400
Received: from sunquest.sunquest.com by ALPHA.SUNQUEST.COM with SMTP;
          Fri, 17 Sep 1993 10:23:58 -0700 (MST)
Received: from ripley.sunquest.com by sunquest.sunquest.com (4.1/SMI-4.1)
	id AA06285; Fri, 17 Sep 93 10:23:54 MST
Received: by ripley.sunquest.com (4.1/SMI-4.1)
	id AA21743; Fri, 17 Sep 93 10:23:43 MST
Date: Fri, 17 Sep 93 10:23:43 MST
From: billb@ripley.sunquest.com (Bill Burcham)
Message-Id: <9309171723.AA21743@ripley.sunquest.com>
To: gnu-objc@prep.ai.mit.edu
Cc: speters@us.oracle.com (Stephen Peters)
In-Reply-To: <9309162333.AA22104@samsun.oracle.com>
Subject: Re: Documentation (long winded)

Stephen Peters writes:
 > 
 > I've been following this thread with some interest, mostly because it
 > was my offer to Andrew McCallum (expressing interest in helping with
 > the Collection library doc) which served to touch off this entire
 > debate. :-)
 > 
 > To my mind, RMS has brought up a very good point -- if we try to
 > structure the manual around TeXinfo extracted from source, what we end
 > up with will most likely be unwieldy for the person who just wants to
 > find out how to create a queue using the Collection objects.
 > Providing a complete manual by topic is better for the person who
 > wants to *use* the objects.
 > 
 > That doesn't mean that I don't think embedding *some* documentation
 > into the source is a bad idea.  In fact, I'm in favor of it.  It will
 > serve very well as a way to provide a "Reference" manual (or perhaps a
 > Referece section to the main manual), and in addition (as Greg Franks
 > noted), it provides an easy way for a class browser to call up
 > documentation on the methods of a class on the fly.
 > 
 > In many ways, however, I think documentation that is so closely linked
 > with the code is best used as a way for the programmer to describe how
 > a function or method works, rather than how it might be used.  To this
 > end, it might make sense to use the TeXinfo'd source to create a
 > separate "Programmer's Reference" manual, which would be little more
 > than a catalog of class methods, but would comment more on the
 > implementation details than on the "big picture".
 > 

Instead of "Programmer's Reference" manual, I would call this a
"Maintainer's Manual", or an "Implementation Specification".  Here in
the Commercial World such a document is of great utility (at least I
_think_ it would be if I ever actually _had_ one -- no one documents
their code properly).

I am sure that such a document would be invaluable to participants in
the GNU Project as well.  The need is exacerbated in the latter case
because it seems to me that as an organization, the GNU Project
(pls. correct me if my terminology is incorrect) is more
geographically dispersed and has higher turnover than most
(traditional) organizations.

So really, we're kind of back to the literate programming thing.  I
think we should tak an approach like that presented in "A Statically
Typed Abstract Representation for C++ Programs", Robert B. Murray,
USENIX C++ Conference Proceedings, Summer 1992, to wit: why not
provide tools that present the semantics of the code in question as
objects, thus eliminating the need for tool writers to write compiler
front-ends in order to extract information about code.

I use SparcWorks C++ which builds a source browsing database.  I can
do queries on this database to, e.g., find all the references to
member function foo: in all the code.  It is useful for me in cases
where etags just doesn't have enough smarts.  What I would really like
is a C++ class library that lets me interface directly to the source
browsing database as just another persistent store of objects
(representing the my software system).  Then I wouldn't be limited to
the pre-defined set of queries that SparcWorks provides, and I would
have all information about the code available to me.

In Murray's paper he mentions that comments are available in the
abstract representation, so if you want to embed special (non C++)
information describing the classes, you can.  Such a system provides
the _framework_ for building literate programming systems (as opposed
to just providing a literate programming system).

 > rms@gnu.ai.mit.edu (Richard Stallman) wrote:
 > >What is crucial is that the GNU project will not adopt standards that
 > >give people the wrong idea about what is good documentation!  We may
 > >not always be able to get good documentation, but we MUST show people
 > >clearly what they should AIM for.
 > 
 > I can't agree with this statement more.  Overall, I've found the GNU
 > info docs to be of very good quality -- often better than what I can
 > find commercially.  The Objective-C docs should certainly make a
 > strong attempt to mirror this quality.

        Bill Burcham         | "It doesn't matter how fast
Sunquest Information Systems |  you _can't_ do something"
     4801 East Broadway      |     602.570.2840 Office
    Tucson, AZ 85711 3610    |     602.570.2099 FAX


From 
To: krab@iesd.auc.dk (Kresten Krab Thorup)
Subject: Changes to gcc objc
Date: Tue, 21 Sep 93 10:20:46 -0400
From: mccallum@cs.rochester.edu

Hi Kresten,

I installed ss-930912, and have been developing libcoll with it.  And
it's been working fine!  Currently I'm in the middle of adding
archiving using write: and read:

Some notes:

In
>  objc_write_type(TypedStream* stream, const char* type, const void* data)
shouldn't
>  case _C_CHARPTR:
>    return objc_write_string (stream, (char*)data, strlen((char*)data));
>    break;
be
>  case _C_CHARPTR:
>    return objc_write_string (stream, *(char**)data, strlen((char*)data));
>    break;
in order to be more consistent?  Also see NeXT's 2.0 Concept's manual.
They have: 
> float   aFloat = 3.0;
> int     anInt = 5;
> char   *aCharStar = "foo";
> 
> NXWriteTypes(typedStream, "fi*", &aFloat, &anInt, &aCharStar);


In
> objc_sizeof_type(const char* type)
the error message cites the wrong function name:
> fprintf(stderr, "objc_write_type: cannot parse typespec: %s\n", type);
The same goes for
> objc_read_type(TypedStream* stream, const char* type, void* data)


I'm having a problem with gcc recognizing that Protocols are being
satisfied.  A class's superclass implements some of the methods in the
protocol attributed to the class, and gcc complains about these
methods not being found.  Fine.  This was expected because I didn't
use the -Wno-protocol flag.  But when I use the flag, gcc complains
that *none* of the methods in the protocol are found (even the ones
that are implemented in the class).  If you need me to come up with a
short example, let me know.


I think I'll make a new release of libcoll after 2.5.x comes out.  Is
there any chance of getting the following into 2.5.x objc? :

* Add -(int)compare:anotherObject; to Object.[hm].
* Add -shouldNotImplement:(SEL)aSel; to Object.
* Make OBJC_MALLOC() and friends public.
* Add hash_node_for_key() to hash.h and hash.c.


Regards,
	Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA15051; Tue, 21 Sep 93 12:14:31 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA06591; Tue, 21 Sep 93 12:14:11 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA11289
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Tue, 21 Sep 1993 18:12:36 +0200
Received: by xiv.iesd.auc.dk id AA03773
  (5.65c8/IDA-CLIENT/MD); Tue, 21 Sep 1993 18:12:53 +0200
Date: Tue, 21 Sep 1993 18:12:53 +0200
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309211612.AA03773@xiv.iesd.auc.dk>
To: Andrew McCallum <mccallum@cs.rochester.edu>
Subject: Re: Changes to gcc objc
Cc: Kresten Krab Thorup <krab@iesd.auc.dk>
Cc: Paul Burchard <burchard@geom.umn.edu>
Cc: Paul Kunz <Paul_Kunz@slac.stanford.edu>
Cc: Mark Zusman <marklz@rotem.technion.ac.il>
Cc: Geoffery Knauth <gsk@marble.com>


[ This is CC'ed to the "insiders" of GNU objective C, since it also
  gives kind of a status overview.  Since a 2.5.x release of gcc is
  coming up soon, please resend any bugfixes I've not installed
  already.  --Kresten ]

Nice hearing from you Andrew!

   I installed ss-930912, and have been developing libcoll with it.  And
   it's been working fine!  Currently I'm in the middle of adding
   archiving using write: and read:

Great.  Paul Kunz fixed a bug in the archiving (read_string), I've
installed it at fsf so it is most possibly in the 930921 snapshot. If
you're having trouble please consider installing that one.  

   Some notes:

   shouldn't [...]
   be [...]
   in order to be more consistent?  Also see NeXT's 2.0 Concept's manual.

Please send me a patch and ChangeLog entry and I will seriously
consider installing it.  You're right that I'm inconsistent there.

   I'm having a problem with gcc recognizing that Protocols are being
   satisfied.  A class's superclass implements some of the methods in the
   protocol attributed to the class, and gcc complains about these
   methods not being found.  Fine.  This was expected because I didn't
   use the -Wno-protocol flag.  But when I use the flag, gcc complains
   that *none* of the methods in the protocol are found (even the ones
   that are implemented in the class).  If you need me to come up with a
   short example, let me know.

That code is buggy.  Please stand by until I get to NeXT, so I can
fix it properly.  I know it is bad...  Please live with it.
-Wno-protocol will occasionally do what you want it to...  posing also
have a bug when a root class is being posed for twice.  

   I think I'll make a new release of libcoll after 2.5.x comes out.

On the NeXT turbo station (68040) nested functions sometime (too
often) barf since the insn cache isn't flushed correctly.  I've found
a way to handle it, and hopefully I can install it before 2.5.  It
would be an absolutely *killer* if we could introduce a libcoll with
GNU objc 2.5 that works even on the NeXT.  I think HPPA and RS/6000
will be supported in the objc runtime as well as of 2.5.

   Is there any chance of getting the following into 2.5.x objc? :

   * Add -(int)compare:anotherObject; to Object.[hm].
   * Add -shouldNotImplement:(SEL)aSel; to Object.
   * Add hash_node_for_key() to hash.h and hash.c.

No problem.  For the OBJC_MALLOC, please rename it *and* __objc_malloc
to objc_malloc in the runtime.  Or do you think we should have
OBJC_MALLOC distinct from objc_malloc?  Think about it.  Please send
me a patch and ChangeLog for this as well.

2 more Q's (this goes for all of you): What machine are you currently
using?  Have you had any problems with the new encoding scheme?  If
possible, would you be kind to try out whatever different
machines/targets you have available?

Kresten

From 
Return-Path: burchard@geom.umn.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA22581; Thu, 23 Sep 93 22:18:40 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/z) id AA20638; Thu, 23 Sep 93 22:18:22 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Thu, 23 Sep 1993 21:17:23 -0500
Date: Thu, 23 Sep 93 21:17:18 -0500
From: burchard@geom.umn.edu
Message-Id: <9309240217.AA00869@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Thu, 23 Sep 93 21:17:18 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Re: Changes to gcc objc
Cc: Andrew McCallum <mccallum@cs.rochester.edu>,
        Kresten Krab Thorup <krab@iesd.auc.dk>,
        Paul Burchard <burchard@geom.umn.edu>,
        Paul Kunz <Paul_Kunz@slac.stanford.edu>,
        Mark Zusman <marklz@rotem.technion.ac.il>,
        Geoffery Knauth <gsk@marble.com>

Can anyone tell me the status of the following issues?  I haven't  
heard anything about them for several months, and with 2.5.x coming  
up I'd like them to get a serious hearing...

1.  We need to add a predefine __XXX_OBJC_RUNTIME__ corresponding to  
each -fxxx-runtime switch, so that it is possible to write code that  
will compile for both GNU and NeXT runtimes.  (In particular one  
could create a compatibility header file for the two runtimes.)  I  
submitted a correct patch for this, but RMS wanted to hold off on  
making a decision about this until after 2.4.0.  What has happened to  
this?

2.  For the basic copy protocol, we need to sort out if there should  
be a difference between -shallowCopy and -allocCopy.  The need for  
such a distinction (which I overlooked in my original proposal for  
the copy protocol) came up in libcoll, and I believe collection  
classes make excellent "canaries in the OOP coal mine".  Since the  
GNU copy protocol is already a proper (albeit compatible) extension  
of NeXT's, we should make sure we do it right.  The sooner this is  
resolved the easier it will be...

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

From 
To: burchard@geom.umn.edu
CC: Kresten Krab Thorup <krab@iesd.auc.dk>,
    Paul Kunz <Paul_Kunz@slac.stanford.edu>,
    Mark Zusman <marklz@rotem.technion.ac.il>,
    Geoffery Knauth <gsk@marble.com>
Subject: Re: Changes to gcc objc 
In-reply-to: Your message of "Thu, 23 Sep 93 21:17:18 CDT."
             <9309240217.AA00869@mobius.geom.umn.edu> 
Date: Mon, 27 Sep 93 12:49:24 -0400
From: mccallum@cs.rochester.edu

Hi ObjC insiders,

>> On Thu, 23 Sep 93 21:17:18 -0500, burchard@geom.umn.edu said:

b> 2.  For the basic copy protocol, we need to sort out if there should  
b> be a difference between -shallowCopy and -allocCopy.  The need for  
b> such a distinction (which I overlooked in my original proposal for  
b> the copy protocol) came up in libcoll, and I believe collection  
b> classes make excellent "canaries in the OOP coal mine".  Since the  
b> GNU copy protocol is already a proper (albeit compatible) extension  
b> of NeXT's, we should make sure we do it right.  The sooner this is  
b> resolved the easier it will be...

I like this proposal of Paul's better than what we have now.  I also
agree with an earlier message of his:

b> If we  
b> do this, what should be the relationship between -allocCopy,  
b> -shallowCopy, and -copy?  Should they nest or be independent?  (My  
b> inclination would be to make -shallowCopy independent of -copy.) 

In fact this is the way my latest version of libcoll works: it uses an
-allocCopy I defined and -copy is independent of -shallowCopy.

HOWEVER, the more I think about it the more I think it might be best
to get rid of -allocCopy AND object_copy()!  (A fairly radical
proposal which I admittedly haven't thought out completely, but here's
a shot at an explanation for such madness:)

I think ObjC already has too many places that must deal with
initializing the raw instance variable memory: i.e. more than one,
namely the code for -init and -read.  It seems a bit messy to me that
there are two different methods that initialize a newly allocated
object.  If you want any side effect of object initialization for that
class you must duplicate the code.  If later you change one method,
you have to be sure and change the other one too.  I'd love to figure
out a scheme in which -read methods called -init methods.  Programs
could be assured that any time an object was created, it went through
-init; this seems like a useful convention to me.

Anyway, back to copying.  In libcoll, copied collections can't be
simple memcpy()'ed versions of each other.  For example the elt
*_contents_array in the Array class must point to a new hunk of
malloc()'ed memory.  The means that -shallowCopy, or some method like
it, must malloc() some memory and assign the copy's _contents_array to
point to it.  This functionality is also in the designated -init'izer.
Shallowcopy has become yet another place in the code that is
initializing raw instance variable memory.

I think it would be great if ALL object creation went through some
-init method, including object copying.  An object's variables would
get copied because the right parameters were passed to -init and other
methods, not because we did a raw memcpy().

Here's some rough code that might explain my idea a little better:

-newCopy
{
  id copy = [[[self class] alloc] initDesginatedFoo:foo bar:[self bar]];
  [copy setThisVarUnsettableByInit:theVar];
  return copy;
}

-shallowCopy
{
  id copy = [self newCopy];
  [copy addContentsOf:self];
  return copy;
}

-deepCopy
{
  id copy = [self newCopy];
  [self makeObjectsPerform:@selector(addCopyOfObject:) in: copy];
  return self;
}

-copy
{
  return [self deepCopy];  
  /* Could easily be changed to shallowCopy by some subclass in which
     for some reason it made more sense. */
}

Don't hesitate to tell me what's wrong with the proposal.

	Andrew

From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA22559; Mon, 27 Sep 93 15:26:15 -0400
Received: from SERV02.SLAC.Stanford.EDU by cayuga.cs.rochester.edu (5.61/z) id AA07673; Mon, 27 Sep 93 15:25:54 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU (PMDF V4.2-12
 #4747) id <01H3FXJIZKGW0011D7@SERV02.SLAC.STANFORD.EDU>; Mon,
 27 Sep 1993 12:00:20 PDT
Received: by kaon.SLAC.Stanford.EDU (NX5.67d/NX3.0S) id AA18389; Mon,
 27 Sep 93 11:57:26 -0700
Received: by NeXT.Mailer (1.95.RR)
Received: by NeXT Mailer (1.95.RR)
Date: Mon, 27 Sep 1993 11:57:26 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: Changes to gcc objc
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu, Kresten Krab Thorup <krab@iesd.auc.dk>,
        Mark Zusman <marklz@rotem.technion.ac.il>,
        Geoffery Knauth <gsk@marble.com>
Reply-To: Paul_Kunz@SLAC.Stanford.EDU
Message-Id: <9309271857.AA18389@kaon.SLAC.Stanford.EDU>
X-Envelope-To: mccallum@cs.rochester.edu
Content-Transfer-Encoding: 7BIT

>  I think ObjC already has too many places that must deal
>  with initializing the raw instance variable memory: i.e.
>  more than one, namely the code for -init and -read.  It
>  seems a bit messy to me that there are two different
>  methods that initialize a newly allocated object.  If

   I disagree. An object that is instansiated by unarchiving is in a different  
state from one newly allocated.   A newly allocated object has all its  
instance varibles set to 0, while a newly read object has many if not all of  
the set to some value and only needs to receive -awake to finish the job.
   

   So programmically, its [[MyObject alloc] init] while unarchiving it's read:  
followed by awake.   You can put what is every common between the two in some  
other method.

From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA22559; Mon, 27 Sep 93 15:26:15 -0400
Received: from SERV02.SLAC.Stanford.EDU by cayuga.cs.rochester.edu (5.61/z) id AA07673; Mon, 27 Sep 93 15:25:54 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU (PMDF V4.2-12
 #4747) id <01H3FXJIZKGW0011D7@SERV02.SLAC.STANFORD.EDU>; Mon,
 27 Sep 1993 12:00:20 PDT
Received: by kaon.SLAC.Stanford.EDU (NX5.67d/NX3.0S) id AA18389; Mon,
 27 Sep 93 11:57:26 -0700
Received: by NeXT.Mailer (1.95.RR)
Received: by NeXT Mailer (1.95.RR)
Date: Mon, 27 Sep 1993 11:57:26 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: Changes to gcc objc
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu, Kresten Krab Thorup <krab@iesd.auc.dk>,
        Mark Zusman <marklz@rotem.technion.ac.il>,
        Geoffery Knauth <gsk@marble.com>
Reply-To: Paul_Kunz@SLAC.Stanford.EDU
Message-Id: <9309271857.AA18389@kaon.SLAC.Stanford.EDU>
X-Envelope-To: mccallum@cs.rochester.edu
Content-Transfer-Encoding: 7BIT

>  I think ObjC already has too many places that must deal
>  with initializing the raw instance variable memory: i.e.
>  more than one, namely the code for -init and -read.  It
>  seems a bit messy to me that there are two different
>  methods that initialize a newly allocated object.  If

   I disagree. An object that is instansiated by unarchiving is in a different  
state from one newly allocated.   A newly allocated object has all its  
instance varibles set to 0, while a newly read object has many if not all of  
the set to some value and only needs to receive -awake to finish the job.
   

   So programmically, its [[MyObject alloc] init] while unarchiving it's read:  
followed by awake.   You can put what is every common between the two in some  
other method.

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA24929; Mon, 27 Sep 93 16:26:40 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA08062; Mon, 27 Sep 93 16:26:21 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA15381
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 27 Sep 1993 21:25:45 +0100
Received: by xiv.iesd.auc.dk id AA24740
  (5.65c8/IDA-CLIENT/MD); Mon, 27 Sep 1993 21:26:16 +0100
Date: Mon, 27 Sep 1993 21:26:16 +0100
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309272026.AA24740@xiv.iesd.auc.dk>
To: Paul_Kunz@SLAC.Stanford.EDU
Cc: mccallum@cs.rochester.edu, burchard@geom.umn.edu,
        marklz@rotem.technion.ac.il, gsk@marble.com, snaroff@next.com,
        krab@iesd.auc.dk
In-Reply-To: <9309271857.AA18389@kaon.SLAC.Stanford.EDU> (Paul_Kunz@SLAC.Stanford.EDU)
Subject: object initialization


   [I put snaroff on the "insiders" list -- Kresten]

   Paul Kunz writes:
   An object that is instansiated by unarchiving is in a different
   state from one newly allocated.  A newly allocated object has all
   its instance varibles set to 0, while a newly read object has many
   if not all of the set to some value and only needs to receive
   -awake to finish the job.

I think Paul is right here.  There are two things: Initializing from
scratch, and initializing from a stored representation of the object.
>From the outside, you're not supposed to see/know that some
unarchiving ever happened.  However, it would be hazardeous if you
didn't know that some object was properly initialized when you
allocated it.  Thus, I se no reason to have one unified method which
does "basic initialization" as Andrew proposed.

      So programmically, its [[MyObject alloc] init] while unarchiving
   it's read: followed by awake.  You can put what is every common
   between the two in some other method.

The +alloc method is *in principle* used by both actions: +new and
objc_read_object().  Only in the latter case it is the runtime code
which does the allocation (that's nasty I believe... let's change it).
Coming down to the matter, the difference between the two is:

	[XX init]
vs
	[[XX read:s] ...time passes... awake]

where XX is a newly allocated object.  I consider the -read: method to
be equivalent to the fact that newly created objects are all
initialized to zeroes, while -awake is like init.  If that
understanding is right, perhaps -read: should be a class method and
then it should also be responsible for allocating the object.

Another unification that would be much better was mentioned somewhere
several moths ago by Paul Burchard: We need a unified protocol for
archiving *and* distributed objects.  The -read: and -decodeFrom: are
really too much alike to be two different methods.  However, I dont
think we came up with a brilliant ide also covering the <bycopy>
mechanism.

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA24929; Mon, 27 Sep 93 16:26:40 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA08062; Mon, 27 Sep 93 16:26:21 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA15381
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 27 Sep 1993 21:25:45 +0100
Received: by xiv.iesd.auc.dk id AA24740
  (5.65c8/IDA-CLIENT/MD); Mon, 27 Sep 1993 21:26:16 +0100
Date: Mon, 27 Sep 1993 21:26:16 +0100
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309272026.AA24740@xiv.iesd.auc.dk>
To: Paul_Kunz@SLAC.Stanford.EDU
Cc: mccallum@cs.rochester.edu, burchard@geom.umn.edu,
        marklz@rotem.technion.ac.il, gsk@marble.com, snaroff@next.com,
        krab@iesd.auc.dk
In-Reply-To: <9309271857.AA18389@kaon.SLAC.Stanford.EDU> (Paul_Kunz@SLAC.Stanford.EDU)
Subject: object initialization


   [I put snaroff on the "insiders" list -- Kresten]

   Paul Kunz writes:
   An object that is instansiated by unarchiving is in a different
   state from one newly allocated.  A newly allocated object has all
   its instance varibles set to 0, while a newly read object has many
   if not all of the set to some value and only needs to receive
   -awake to finish the job.

I think Paul is right here.  There are two things: Initializing from
scratch, and initializing from a stored representation of the object.
>From the outside, you're not supposed to see/know that some
unarchiving ever happened.  However, it would be hazardeous if you
didn't know that some object was properly initialized when you
allocated it.  Thus, I se no reason to have one unified method which
does "basic initialization" as Andrew proposed.

      So programmically, its [[MyObject alloc] init] while unarchiving
   it's read: followed by awake.  You can put what is every common
   between the two in some other method.

The +alloc method is *in principle* used by both actions: +new and
objc_read_object().  Only in the latter case it is the runtime code
which does the allocation (that's nasty I believe... let's change it).
Coming down to the matter, the difference between the two is:

	[XX init]
vs
	[[XX read:s] ...time passes... awake]

where XX is a newly allocated object.  I consider the -read: method to
be equivalent to the fact that newly created objects are all
initialized to zeroes, while -awake is like init.  If that
understanding is right, perhaps -read: should be a class method and
then it should also be responsible for allocating the object.

Another unification that would be much better was mentioned somewhere
several moths ago by Paul Burchard: We need a unified protocol for
archiving *and* distributed objects.  The -read: and -decodeFrom: are
really too much alike to be two different methods.  However, I dont
think we came up with a brilliant ide also covering the <bycopy>
mechanism.

From 
To: Paul Burchard <burchard@geom.umn.edu>,
    Kresten Krab Thorup <krab@iesd.auc.dk>,
    Paul Kunz <Paul_Kunz@slac.stanford.edu>,
    Mark Zusman <marklz@rotem.technion.ac.il>,
    Geoffery Knauth <gsk@marble.com>, Steve Naroff <snaroff@next.com>
Subject: Re: object initialization 
In-reply-to: Your message of "Mon, 27 Sep 93 21:26:16 BST."
             <199309272026.AA24740@xiv.iesd.auc.dk> 
Date: Mon, 27 Sep 93 17:31:57 -0400
From: mccallum@cs.rochester.edu

Hi folks,

I find myself agreeing with many of the descriptive statements made by
Kresten and Paul, but somehow I'm still coming to different
conclusions.

Perhaps I will be more clear if I'm more concrete:

Consider the implementation of the List class.  There are three
different places where self->dataPtr is initialized with the results
of a malloc():
	- initCount:
	- shallowCopy
	- read:

In ObjC and Smalltalk objects are built by executing a "plan" (as
opposed to a language like Self where "cloning prototypes" is the
basic operation for creating objects).  It is not the case for the
List class, but sometimes this plan can be quite involved.  Often the
plan is NOT just a matter of setting instance variable values: memory
may need to be malloc()'ed, other objects may need to be notified of
the object's creation, etc.

Question:  Am I the only one that thinks it is a bit unfortunate
that this "building plan" for objects must be duplicated in three
places?

The way I see it all three of the above methods do basically
the same thing, they build an object given certain parameters, they
just happen to get their parameters from different places:  -init:...
from its arguments, -shallowCopy from the receiver's instance vars,
and -read: from the typed stream.

If no one agrees that this is unfortunate, no big deal.  We'll go and
work on other things. 

If someone agrees, then we can think together trying to come up with
something better.

	-Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From 
To: Paul Burchard <burchard@geom.umn.edu>,
    Kresten Krab Thorup <krab@iesd.auc.dk>,
    Paul Kunz <Paul_Kunz@slac.stanford.edu>,
    Mark Zusman <marklz@rotem.technion.ac.il>,
    Geoffery Knauth <gsk@marble.com>, Steve Naroff <snaroff@next.com>
Subject: Re: libcoll 
In-reply-to: Your message of "Mon, 27 Sep 93 21:29:53 BST."
             <199309272029.AA24755@xiv.iesd.auc.dk> 
Date: Mon, 27 Sep 93 17:40:08 -0400
From: mccallum@cs.rochester.edu

>> On Mon, 27 Sep 1993 21:29:53 +0100, Kresten Krab Thorup <krab@iesd.auc.dk> said:

KKT> Now that we have a snapshot with (hopefully) 68040 trampolines
KKT> working, could you make a beta release of libcoll for the insiders to
KKT> test before gcc 2.5 release?   I would love to be able to present a
KKT> GNU Objective-C that came with a working collection library even on
KKT> NeXT.

Yes!  I would like to get the internal feedback, and I'm also
extremely excited to get libcoll running on a NeXT!  I would love for
NeXT-folk to find it useful.

When is 2.5 scheduled to be released?  I could give you all the
current copy right away if that's what you want.  It *is* in a working
state, but you should all be wary that it definitely not in a polished
world-releasable state. 

Regards,
	Andrew

From 
Return-Path: Steve_Naroff@NeXT.COM
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA27688; Mon, 27 Sep 93 17:52:51 -0400
Received: from next.com by cayuga.cs.rochester.edu (5.61/z) id AA08599; Mon, 27 Sep 93 17:52:33 -0400
Received: from nomad by oz.NeXT.COM (NX5.67d/NeXT0.1-Aleph-bf)
	id AA26858; Mon, 27 Sep 93 14:52:32 -0700
From: Steve_Naroff@NeXT.COM (Steve Naroff)
Message-Id: <9309272152.AA26858@oz.NeXT.COM>
Received: by nomad.next.com (NX5.67d/NX3.0X)
	id AA10767; Mon, 27 Sep 93 14:52:29 -0700
Date: Mon, 27 Sep 93 14:52:29 -0700
Received: by NeXT.Mailer (1.97.1)
Received: by NeXT Mailer (1.97.1)
To: mccallum@cs.rochester.edu
Subject: Re: object initialization 
Cc: Paul Burchard <burchard@geom.umn.edu>,
        Kresten Krab Thorup <krab@iesd.auc.dk>,
        Paul Kunz <Paul_Kunz@slac.stanford.edu>,
        Mark Zusman <marklz@rotem.technion.ac.il>,
        Geoffery Knauth <gsk@marble.com>, Steve Naroff <snaroff@NeXT.COM>


Question:  Am I the only one that thinks it is a bit unfortunate
that this "building plan" for objects must be duplicated in three
places?

I agree, it is not great programming style to have this kind of  
duplication (unless there is a good reason). I try and strive for  
"single point of control" whenever possible...however this is hard to  
achieve in practice (due to lack of time). 


Since libcoll is new (and not to big), it probably makes sense to  
start off on the right foot (as you suggest).

snaroff.

From 
Return-Path: Steve_Naroff@NeXT.COM
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA27688; Mon, 27 Sep 93 17:52:51 -0400
Received: from next.com by cayuga.cs.rochester.edu (5.61/z) id AA08599; Mon, 27 Sep 93 17:52:33 -0400
Received: from nomad by oz.NeXT.COM (NX5.67d/NeXT0.1-Aleph-bf)
	id AA26858; Mon, 27 Sep 93 14:52:32 -0700
From: Steve_Naroff@NeXT.COM (Steve Naroff)
Message-Id: <9309272152.AA26858@oz.NeXT.COM>
Received: by nomad.next.com (NX5.67d/NX3.0X)
	id AA10767; Mon, 27 Sep 93 14:52:29 -0700
Date: Mon, 27 Sep 93 14:52:29 -0700
Received: by NeXT.Mailer (1.97.1)
Received: by NeXT Mailer (1.97.1)
To: mccallum@cs.rochester.edu
Subject: Re: object initialization 
Cc: Paul Burchard <burchard@geom.umn.edu>,
        Kresten Krab Thorup <krab@iesd.auc.dk>,
        Paul Kunz <Paul_Kunz@slac.stanford.edu>,
        Mark Zusman <marklz@rotem.technion.ac.il>,
        Geoffery Knauth <gsk@marble.com>, Steve Naroff <snaroff@NeXT.COM>


Question:  Am I the only one that thinks it is a bit unfortunate
that this "building plan" for objects must be duplicated in three
places?

I agree, it is not great programming style to have this kind of  
duplication (unless there is a good reason). I try and strive for  
"single point of control" whenever possible...however this is hard to  
achieve in practice (due to lack of time). 


Since libcoll is new (and not to big), it probably makes sense to  
start off on the right foot (as you suggest).

snaroff.

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA28758; Mon, 27 Sep 93 18:30:38 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA08799; Mon, 27 Sep 93 18:30:19 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA16384
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 27 Sep 1993 23:28:53 +0100
Received: by xiv.iesd.auc.dk id AA25193
  (5.65c8/IDA-CLIENT/MD); Mon, 27 Sep 1993 23:29:25 +0100
Date: Mon, 27 Sep 1993 23:29:25 +0100
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309272229.AA25193@xiv.iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu, Paul_Kunz@slac.stanford.edu,
        krab.marklz@rotem.technion.ac.il, gsk@marble.com, snaroff@next.com
In-Reply-To: <9309272131.AA27143@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: object initialization 


   The way I see it all three of the above methods do basically
   the same thing, they build an object given certain parameters, they
   just happen to get their parameters from different places:  -init:...
   from its arguments, -shallowCopy from the receiver's instance vars,
   and -read: from the typed stream.

Ok, I get your point.  But then the *ultimate* solution would be some
way to make a generic protocol for "source of initialization", and
make -read: (or something equivalent) able to utilize that protocol.

Imagine that we have only -read:, and that -shallowCopy in principle
is implemented as a copy of itself written and then read from a memory
typed stream:

  -shallowCopy
  {
    id result;
    TypedStream *ms = open_in_memory_typed_stream ();
    objc_write_object (ms, self);
    result = objc_read_object (ms);
    close_typed_stream (ms);
    return result;
  }

Then what we need is some way to create a meaningful typedstream from
some arguments (to -initFromArgs:...).  Although this is redicilous,
what I mean is something like:

  -initFromArgs: (int)a1 and: a2 and: a3
  {
    id result;
    TypedStream *ms = open_in_memory_typed_stream ();

    // This is how to pass info on to -read:
    self->listSize = a1; 

    objc_write_object (ms, self);
    result = objc_read_object (ms);

    // initialize the rest
    result->ivar2 = a2;
    result->ivar3 = a3;

    close_typed_stream (ms);
    return result;
  }

This is not fully foolproof and has some holes with [super init], but
perhaps the idea is worth thinking about...

Just some random ...

Kresten

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA28828; Mon, 27 Sep 93 18:32:37 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA08807; Mon, 27 Sep 93 18:32:17 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA16408
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 27 Sep 1993 23:30:55 +0100
Received: by xiv.iesd.auc.dk id AA25205
  (5.65c8/IDA-CLIENT/MD); Mon, 27 Sep 1993 23:31:26 +0100
Date: Mon, 27 Sep 1993 23:31:26 +0100
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309272231.AA25205@xiv.iesd.auc.dk>
To: mccallum@cs.rochester.edu
Cc: burchard@geom.umn.edu, Paul_Kunz@slac.stanford.edu, krab@iesd.auc.dk,
        marklz@rotem.technion.ac.il, gsk@marble.com, snaroff@next.com
In-Reply-To: <9309272131.AA27143@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: object initialization 


   [Sorry if you get this twice, I messed up the header -- Kresten]

   The way I see it all three of the above methods do basically
   the same thing, they build an object given certain parameters, they
   just happen to get their parameters from different places:  -init:...
   from its arguments, -shallowCopy from the receiver's instance vars,
   and -read: from the typed stream.

Ok, I get your point.  But then the *ultimate* solution would be some
way to make a generic protocol for "source of initialization", and
make -read: (or something equivalent) able to utilize that protocol.

Imagine that we have only -read:, and that -shallowCopy in principle
is implemented as a copy of itself written and then read from a memory
typed stream:

  -shallowCopy
  {
    id result;
    TypedStream *ms = open_in_memory_typed_stream ();
    objc_write_object (ms, self);
    result = objc_read_object (ms);
    close_typed_stream (ms);
    return result;
  }

Then what we need is some way to create a meaningful typedstream from
some arguments (to -initFromArgs:...).  Although this is redicilous,
what I mean is something like:

  -initFromArgs: (int)a1 and: a2 and: a3
  {
    id result;
    TypedStream *ms = open_in_memory_typed_stream ();

    // This is how to pass info on to -read:
    self->listSize = a1; 

    objc_write_object (ms, self);
    result = objc_read_object (ms);

    // initialize the rest
    result->ivar2 = a2;
    result->ivar3 = a3;

    close_typed_stream (ms);
    return result;
  }

This is not fully foolproof and has some holes with [super init], but
perhaps the idea is worth thinking about...

Just some random ...

Kresten

From 
Return-Path: burchard@geom.umn.edu
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA29516; Mon, 27 Sep 93 18:54:07 -0400
Received: from cameron.geom.umn.edu by cayuga.cs.rochester.edu (5.61/z) id AA08941; Mon, 27 Sep 93 18:53:48 -0400
Received: from mobius.geom.umn.edu by cameron.geom.umn.edu; Mon, 27 Sep 1993 17:52:23 -0500
Date: Mon, 27 Sep 93 17:52:19 -0500
From: burchard@geom.umn.edu
Message-Id: <9309272252.AA06732@mobius.geom.umn.edu>
Received: by mobius.geom.umn.edu; Mon, 27 Sep 93 17:52:19 -0500
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Kresten Krab Thorup <krab@iesd.auc.dk>
Subject: Re: object initialization 
Cc: mccallum@cs.rochester.edu, burchard@geom.umn.edu,
        Paul_Kunz@slac.stanford.edu, krab@iesd.auc.dk,
        marklz@rotem.technion.ac.il, gsk@marble.com, snaroff@next.com

> But then the *ultimate* solution
> would be some way to make a generic protocol for "source of
> initialization", and make -read: (or something
> equivalent) able to utilize that protocol. 


I'm with you in spirit.  However, as for your example...

>   -shallowCopy
>   {
>     id result;
>     TypedStream *ms = open_in_memory_typed_stream ();
>     objc_write_object (ms, self);
>     result = objc_read_object (ms);
>     close_typed_stream (ms);
>     return result;
>   }

...this is actually a pretty good implementation of -deepCopy.  What  
it returns is guaranteed to be a completely independent copy.

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA29678; Mon, 27 Sep 93 18:58:37 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA08985; Mon, 27 Sep 93 18:58:19 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA16665
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Mon, 27 Sep 1993 23:57:44 +0100
Received: by xiv.iesd.auc.dk id AA25305
  (5.65c8/IDA-CLIENT/MD); Mon, 27 Sep 1993 23:58:16 +0100
Date: Mon, 27 Sep 1993 23:58:16 +0100
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309272258.AA25305@xiv.iesd.auc.dk>
To: mccallum@cs.rochester.edu
In-Reply-To: <9309272140.AA27340@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libcoll 
Cc: krab@iesd.auc.dk


   When is 2.5 scheduled to be released?  

RMS said <Wed, 15 Sep 93 18:12:50>:

     I'm thinking of releasing 2.5 in early October.  This should make
     it possible to get a stable 2.5.n in time for our next CD-ROM.

I filed a request on (form R-822) to RMS asking for up-to-date info on
this question.  An answer is expected in less than 45 days.

   I could give you all the current copy right away if that's what you
   want.

Something like that would be nice.  I don't have a lot of code to try
it on, but I'd like just to read the source an imagine one.

   It *is* in a working state, but you should all be wary that it
   definitely not in a polished world-releasable state.

Didn't you get feedback from some more people?  Anyway, having it
running on NeXT makes the potential for feedback much bigger.  

Kresten

From 
Return-Path: krab@iesd.auc.dk
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA29818; Mon, 27 Sep 93 19:02:05 -0400
Received: from iesd.auc.dk by cayuga.cs.rochester.edu (5.61/z) id AA08999; Mon, 27 Sep 93 19:01:46 -0400
Received: from xiv.iesd.auc.dk by iesd.auc.dk with SMTP id AA16699
  (5.65c8/IDA-1.5/MD for <mccallum@cs.rochester.edu>); Tue, 28 Sep 1993 00:01:12 +0100
Received: by xiv.iesd.auc.dk id AA25317
  (5.65c8/IDA-CLIENT/MD); Tue, 28 Sep 1993 00:01:44 +0100
Date: Tue, 28 Sep 1993 00:01:44 +0100
From: Kresten Krab Thorup <krab@iesd.auc.dk>
Message-Id: <199309272301.AA25317@xiv.iesd.auc.dk>
To: burchard@geom.umn.edu
Cc: mccallum@cs.rochester.edu, burchard@geom.umn.edu,
        Paul_Kunz@slac.stanford.edu, marklz@rotem.technion.ac.il,
        gsk@marble.com, snaroff@next.com, krab@iesd.auc.dk
In-Reply-To: <9309272252.AA06732@mobius.geom.umn.edu> (burchard@geom.umn.edu)
Subject: Re: object initialization 



   I'm with you in spirit.  However, as for your example...
   
   >   -shallowCopy
   >   {
   >     id result;
   >     TypedStream *ms = open_in_memory_typed_stream ();
   >     objc_write_object (ms, self);
   >     result = objc_read_object (ms);
   >     close_typed_stream (ms);
   >     return result;
   >   }
   
   ...this is actually a pretty good implementation of -deepCopy.  What  
   it returns is guaranteed to be a completely independent copy.

This depends on how "deep" -write: goes!  But I think this can be
handled by something like the Encoding/Decoding protocol of DO's
applied to typedstreams.  You had some good suggestions on this a long
time ago...

Kresten

From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/z) id AA01521; Mon, 27 Sep 93 19:49:03 -0400
Received: from SERV02.SLAC.Stanford.EDU by cayuga.cs.rochester.edu (5.61/z) id AA09169; Mon, 27 Sep 93 19:48:42 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU (PMDF V4.2-12
 #4747) id <01H3G7D7VQM80015PA@SERV02.SLAC.STANFORD.EDU>; Mon,
 27 Sep 1993 16:41:23 PDT
Received: by kaon.SLAC.Stanford.EDU (NX5.67d/NX3.0S) id AA19045; Mon,
 27 Sep 93 16:39:46 -0700
Received: by NeXT.Mailer (1.95.RR)
Received: by NeXT Mailer (1.95.RR)
Date: Mon, 27 Sep 1993 16:39:46 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: Re: object initialization
To: mccallum@cs.rochester.edu
Cc: Paul Burchard <burchard@geom.umn.edu>,
        Kresten Krab Thorup <krab@iesd.auc.dk>,
        Mark Zusman <marklz@rotem.technion.ac.il>,
        Geoffery Knauth <gsk@marble.com>, Steve Naroff <snaroff@next.com>
Reply-To: Paul_Kunz@SLAC.Stanford.EDU
Message-Id: <9309272339.AA19045@kaon.SLAC.Stanford.EDU>
X-Envelope-To: mccallum@cs.rochester.edu
Content-Transfer-Encoding: 7BIT

>  

>  I find myself agreeing with many of the descriptive
>  statements made by Kresten and Paul, but somehow I'm
>  still coming to different conclusions.
>  

   Maybe you're focusing too much on one particular class implementation or  
needs of libcoll.   In my case, our (yet unannounced) class library of about  
30 classes, there are 3 main inheritence groups...
   

- one of them inherits -awake from Object, thus nothing needs to be done after   
read:  In this group, doing an init before read: is a wasted effort because  
there's nothing to initialize.

- one group does [self init] in the awake method of a super class.   An init  
before the read would be wasted.   In this case, we've not duplicated any  
code.

- the last group does [self init] followed by a few [self setXXX:aValue]'s in  
the awake of a super class.   Here we've avoided duplication by using the  
setXXX: methods.

   I therefore come to the conclusion that the archiving system can't know if  
it is appropriate to init or not.   All it can do is allocate space for read:  
to fill in, and perhaps awake to finish off.
   

   I've looked into your List class and see why you implemented the way you  
did.   Its much more efficient code then if you had tried to avoid  
duplication.
   

To: gcc2@cygnus.com
Subject: Nested Functions outside their defining blocks
Date: Fri, 29 Oct 93 16:53:13 -0400
From: mccallum@cs.rochester.edu

Can the following macro be counted on?

#define LAMBDA(RETTYPE, ARGS, BODY) \
({RETTYPE __lambda_func ARGS BODY __lambda_func;})

as in:
	void myfunc()
	  {
		int a[10];
		...
		qsort(a, 10, sizeof(int), 
		      LAMBDA(int, (int *a, int *b), {return *i - *j;}));
	  }

gcc.info says:
	If you try to call the nested function through its address
	after the containing function has exited, all hell will break
	loose. 

But here I'm using the calling the function outside its containing {}
block, not its "containing function".

It seems to be working just fine on my sparc; I just need to know if I
can rely on it working with other machines too.

	Thanks,
		Andrew

 --------------------------------------------------------------
R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
University of Rochester       VOX: (716) 275-2527
Rochester, NY  14627-0226     FEET: CSB  Rm. 625

From kenner@vlsi1.ultra.nyu.edu  Fri Oct 29 17:18:33 1993
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/A) id AA1
3057; Fri, 29 Oct 93 17:18:33 -0400
Received: from VLSI1.ULTRA.NYU.EDU by cayuga.cs.rochester.edu (5.61/A) id AA0484
9; Fri, 29 Oct 93 17:18:41 -0400
Received: by vlsi1.ultra.nyu.edu (5.61/1.34)
        id AA01506; Fri, 29 Oct 93 17:20:55 -0400
Date: Fri, 29 Oct 93 17:20:55 -0400
From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Message-Id: <9310292120.AA01506@vlsi1.ultra.nyu.edu>
To: mccallum@cs.rochester.edu
Subject: Re:  Nested Functions outside their defining blocks

        But here I'm using the calling the function outside its containing {}
        block, not its "containing function".

You can use it outside it's containing block (unless, of course, it
references variables in that block), but not outside it's containing
function.  Doing so isn't particularly clean, but will work and is
probably OK is a self-contained a case as that macro.

From rms@gnu.ai.mit.edu  Sat Oct 30 03:31:25 1993
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/A) id AA2
4992; Sat, 30 Oct 93 03:31:25 -0400
Received: from mole.gnu.ai.mit.edu by cayuga.cs.rochester.edu (5.61/A) id AA0642
9; Sat, 30 Oct 93 03:31:32 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
        id <AA00179@mole.gnu.ai.mit.edu>; Sat, 30 Oct 93 03:31:21 -0400
Date: Sat, 30 Oct 93 03:31:21 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9310300731.AA00179@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <9310292053.AA12478@slate.cs.rochester.edu> (mccallum@cs.rochester.
edu)
Subject: Re: Nested Functions outside their defining blocks

Here's how I think it is:

If you try to call the nested function through its address after the
containing function has exited, all hell will break loose.  If you try
to call it after a containing scope level has exited, and if it refers
to some of the variables that are no longer in scope, you may be lucky,
but it's not wise to take the risk.  If, however, the nested function
does not refer to anything that has gone out of scope, you should be
safe.

If this turns out to be false, please tell me.

From wilson@cygnus.com  Mon Nov  1 16:50:39 1993
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/A) id AA1
5171; Mon, 1 Nov 93 16:50:39 -0500
Received: from relay1.UU.NET by cayuga.cs.rochester.edu (5.61/A) id AA15694; Mon
, 1 Nov 93 16:50:43 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP 
        (5.61/UUNET-internet-primary) id AB16963; Mon, 1 Nov 93 16:50:13 -0500
Received: from sphagnum.cygnus.com by cygnus.com (4.1/SMI-4.1)
        id AA02431; Mon, 1 Nov 93 13:50:08 PST
Date: Mon, 1 Nov 93 13:50:08 PST
From: wilson@cygnus.com (Jim Wilson)
Message-Id: <9311012150.AA02431@cygnus.com>
To: mccallum@cs.rochester.edu
Subject: Re:  Nested Functions outside their defining blocks


        Can the following macro be counted on?

        #define LAMBDA(RETTYPE, ARGS, BODY) \
        ({RETTYPE __lambda_func ARGS BODY __lambda_func;})

I would expect this to work, but I wouldn't guarantee it as I haven't
studied the code.

There are two issues here I think.  The static chain pointer (which gives
a pointer to the variables of the parent), and the scope of visible variables.

As long as you use the function which the containing function, the static
chain pointer should always be valid, because it is a function specific
value.

However, if you use a nested function outside its containing block, then you
should be careful that you never access any variables which are inside
the containing block.  They will be visible (in scope) to the nested
function, but it won't be valid to use them outside the block they
were defined in.

Jim

From alexk@research.otc.com.au  Tue Nov  9 18:45:39 1993
Received: from cayuga.cs.rochester.edu by slate.cs.rochester.edu (5.61/A) id AA2
1851; Tue, 9 Nov 93 18:45:39 -0500
Received: from amalfi.trl.OZ.AU by cayuga.cs.rochester.edu (5.61/A) id AA26098; 
Tue, 9 Nov 93 18:45:43 -0500
Received: from otcgpo.isg.otc.com.au ([134.159.16.100]) by amalfi.trl.OZ.AU (8.6
.4/8.6.beta.2) with SMTP id KAA06389 for <mccallum@cs.rochester.edu>; Wed, 10 No
v 1993 10:45:28 +1100
From: alexk@research.otc.com.au
Received: from turin.research.otc.com.au (mailhost.research.otc.com.au) by otcgp
o.isg.otc.com.au (4.1/OTC_GPO.2.2)
        id AA15868; Tue, 9 Nov 93 23:45:22 GMT
Received: from milan-bb.research.otc.com.au by turin.research.otc.com.au with SM
TP id AA18144
  (5.65c/IDA-1.4.4 for mccallum@cs.rochester.edu); Wed, 10 Nov 1993 10:46:49 +11
00
Message-Id: <199311092346.AA18144@turin.research.otc.com.au>
To: mccallum@cs.rochester.edu
Subject: Suggestions for libcoll
Date: Wed, 10 Nov 93 10:46:32 +1100


I have come across for a need for a class similar to String but supports
arbitauray lenght strings that can contain nulls anywhere in the string.

You come accross such strings in encoding/decoding of various 
communications protocols including SNMP.

I'm thinking of a class, called something like Buffer, which would be 
similar to operation to the class String.

Apart from that I've been using libcoll with great success, porting an
SNMP client library from C++ to Objective-C.  It's quite good.

Alex Kowalenko                      ACSnet: alexk@research.otc.com.au
Contractor                          Phone:  +61 2 2873131 
Network Management & OSS            Fax:    +61 2 2873299
Telstra                             Mail:  GPO Box 7000, Sydney 2001, Australia

From nisse@lysator.liu.se  Tue May 24 17:05:36 1994
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) 
by slate.cs.rochester.edu (8.6.7/G) with ESMTP id RAA03743 for <mccallum>; Tue, 
24 May 1994 17:05:29 -0400
From: nisse@lysator.liu.se
Received: from godot.lysator.liu.se (root@[130.236.253.6]) by cayuga.cs.rocheste
r.edu (8.6.7/G) with ESMTP id RAA02253 for <mccallum@cs.rochester.edu>; Tue, 24 
May 1994 17:05:20 -0400
Received: from rune.lysator.liu.se (nisse@rune.lysator.liu.se [130.236.254.23]) 
by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id XAA23392 for <mccallum@cs.
rochester.edu>; Tue, 24 May 1994 23:05:01 +0200
Received: (from nisse@localhost) by rune.lysator.liu.se (8.6.8.1/8.6.6) id XAA01
473; Tue, 24 May 1994 23:04:46 +0200
Date: Tue, 24 May 1994 23:04:46 +0200
To: mccallum@cs.rochester.edu
Subject: libcoll

I have compiled your libcoll-940510 on my A1200, and I want to send
you a simple bugfix and a lot of comments.

One collection class that I have missed is a keyed and sorted
collection, with objects as keys. For example, one might use Time
objects as keys. I have started to write a class KeyedSortedQueue,
implemented using the LinkedList class, and while doing this I noticed
some small bugs in the LinkedList class. I have attached the patches
to the end of this message.

The -removeElementAtIndex: method should return the removed element,
but it returns self.
The -successorOfElement and - predeccessorOfElement methods are not
overridden. 

I think that for the LinkedList class it would make sense to let the
last two methods return nil if there is no successor or predecessor,
after all nil objects or NULL pointers can't be stored directly in a
LinkedList. Perhaps the NO_ELEMENT_FOUND_ERROR() macro should be
redefined in the LinkedList.m file to return nil.

In the family of enumerating functions, I want to propose yet another
variant that is something in between -detectObjectByCalling: and
-withObjectsCall:WhileTrue: I want something similar to the lisp OR
form, it returns the first "value" that is non-nil. Here "value"
refers to a return value from aFunc, that can be integer or pointer type.

- withElementsCallUntilTrue: (void *(*aFunc)(elt) ); /* Not tested */
/* aFunc returns a generic pointer */
{
	void *enumState = [self newEnumState];
	void *result = NULL;
	elt e;

	while ((e = [self getNextElement:&e withEnumState:&enumState])
	       && ((result = aFunc(e)) == NULL) )
	;
	[self freeEnumState:&enumState];
	return result;
}

I also have some thoughts about the issue of reference counting /
garbage collection. Objects, especially when kept in collections, must
be considered as "shared" between different classes or modules of
code, that should not need to know of each other.

I start with an example; say that I have a function for getting
objects somewhere from, and then adds them to different collections
depending on their properties.

exampleFunc(id *coll1, id *coll2) 
{
	id obj;

	coll1 = [MyCollClass new]; coll2 = [OtherCollClass new];
	while (obj = get_an_object_somehow() ) {
	  if ([obj hasProperty1])
		[coll1 addObject: obj];
	  if ([obj hasProperty2])
		[coll2 addObject: obj];
	}
}

After calling exampleFunc, there is no way for either of the two
collections to know which objects they "own". When they are freed, by
-free or -freeObjects, or any other method, either too many or too
few objects are deallocated. The problem is that the two collections
should not need to know of the other's existence.

A similar situation occurs in a filesystem with links. Several users,
that might not even know each other, can have one link each to a common
file. When someone deletes his link, the filesystem can't delete the
file unless the other links have already been deleted too. When the
last link is deleted, the file is removed.

I think that a reference count is a good solution. I know this is not
a new idea, and that perhaps this is exactly the way you have planned,
but nevertheless I'll try to make myself clear and explain how I think
this should work.

The idea is simple, keep a reference counter with each object.
Whenever the object is passed to some piece of code (a class's methods
for example) that decides to keep a pointer to the object, the
reference count is incremented. The caller doesn't even need to know
that the called code keeps an own pointer. When the same piece of code
is finished with the object, it sends it the -free message. This
decrements the count, and deallocates the object when the count
reaches zero.

Ordinary messages that extracts some member of a collection without
removing it, like -minObject, does not touch the count. But if the
sender of that message decides to keep the result he might want to
send it the -addReference message, and in that case he later has to
-free it. It is always the same code that calls -addReference that is
responsible for calling -free, with one exception: If an object is
removed from a collection and returned, the reference count is not
decremented. In this case it is the one who calls -remove... that is
responsible for freeing the object if he doesn't need it.

Note that with this scheme old code will not break, as every object is
guaranteed to exist between -new and -free. But the old code may need
an additional -free to actually deallocate the object, if it has been
passed to some collection that takes advantage of the reference count.
Below in @implementation ReferenceCounterObject is an attempt to solve
this problem.

As you have understood by now, I think that reference counting is
important, especially in connection with collection classes.
Personally, I would like to have the reference count added in the
object class. I proposed that to Kresten, rather long time ago, but he
didn't like the idea of an extra instance variable in *every* object,
and I think he has a point there.

I think these ideas are also applicable when support for the
ReferenceCounting protocol is added, with the additional overhead of
checking each object to conform to that protocol.

This is a root class of an object with a reference count that could be useful:

@interface ReferenceCounterObject : Object <ReferenceCounting> {
  unsigned references;
}
- reallyFree;
@end

@implementation ReferenceCounterObject
- init {
  [super init];
#ifdef HACK
  references = 0; /* See discussion below */
#else
  references = 1;
  return self;
}
- (unsigned) references { return references; }
- addReference {
  references++;
  return self;
}
- free { /* This can be inherited by all subclasses */
  if ((references--) <= 1) /* If count is 1 or 0, deallocate. */
    return [self reallyFree];
  else
    return self;
}
- reallyFree { return [super free]; } /* This is for overriding in subclasses */
@end  

The HACK above might make the reference counting a little more
intuitive, at the cost of some logic. It addresses one difference
between operation with and without reference counting: Without
reference counting, the proper way to create an object and add it to a
collection is [aColl addObject:[someClass new]]. The proper way to do
the same with reference counting and without the HACK is:
	id obj = [someClass new];
	[aColl addObject: obj]; /* Here the count gets incremented to 2 */
	[obj free]; /* Must free, as *this* part of the code is
		     * finished with it! This may look strange,
		     * especially if one doesn't know that aColl uses
		     * reference counting!
		     * Now the count is 1 again. */

I'll try to explain the HACK. If -addReference is never called, references
stays at zero, and the first -free message will deallocate the object,
just as it is supposed to do. This works because -free test references
to be 1 or 0 (!) before it is decremented.

If -addReference is called, like in [aColl addObject: [someClass
new]], references is set to 1. That is, there is one owner of the
object, and we must agree that now aColl is the (single) owner of the
object. In effect, the first call to -addReference does *not* add a
reference, instead it transfers ownership from the one who created the
object to the one who calls -addReference. Subsequent -addReference
messages adds references as usual.

Now have a second look at the exampleFunc() above. Without HACK, a
[obj free]; should be added at the end of that function, which is
logical but incompatible with non-reference counting collections. With
HACK, the function should send the -free message only if obj was not
added to any of the two collections. I think this is compatible with
current use of -free, and perhaps more intuitive than "strict"
reference counting.

To end this long message, I want to repeat that I think that some kind
of reference counting is necessary, but I see that it is tricky to get
it to work right *and* be compatible with (old) classes that don't use
it.  Perhaps using HACK above is a reasonable solution. Please let me
know what you think.

And of course, if get my KeyedSortedQueue class finished, I'll send it
to you.

Regards,
	Niels Mvller
	nisse@lysator.liu.se

Small bug fix follows:
------------------------------------8<-------------------------------
*** LinkedList.m.orig	Sat May 21 20:50:13 1994
--- LinkedList.m	Sat May 21 21:15:41 1994
***************
*** 182,189 ****
  - (elt) removeElementAtIndex: (unsigned)index
  {
    CHECK_INDEX_RANGE_ERROR(index, _count);
!   [self removeElement:[self elementAtIndex:index]];
!   return self;
  }
  
  - (elt) elementAtIndex: (unsigned)index
--- 182,188 ----
  - (elt) removeElementAtIndex: (unsigned)index
  {
    CHECK_INDEX_RANGE_ERROR(index, _count);
!   return [self removeElement:[self elementAtIndex:index]];
  }
  
  - (elt) elementAtIndex: (unsigned)index
***************
*** 216,221 ****
--- 215,237 ----
    else
      return NO_ELEMENT_FOUND_ERROR();
  }
+ 
+ - (elt) successorOfElement: (elt)oldElement
+ {
+   id nextElement = [oldElement.id_u nextLink];
+   if (_first_link == nextElement)
+     return NO_ELEMENT_FOUND_ERROR();
+   else
+     return nextElement;
+ }
+ 
+ - (elt) predecessorOfElement: (elt)oldElement
+ {
+   if (_first_link == oldElement.id_u)
+     return NO_ELEMENT_FOUND_ERROR();
+   else
+     return [oldElement.id_u prevLink];
+ }
  
  - (BOOL) getNextElement:(elt *)anElementPtr withEnumState: (void**)enumState
  {

From 
To: nisse@lysator.liu.se
Fcc: +outbox
Subject: Re: libcoll 
In-reply-to: Your message of "Tue, 24 May 94 23:04:46 +0200."
             <199405242104.XAA01473@rune.lysator.liu.se> 
--------
Thanks so much for your bug reports, suggestions and ideas!

* I fixed LinkedList -removeElementAtIndex:

* I added successor and predeccessor to LinkedList.

* I understand why is a pain to have NO_ELEMENT_FOUND_ERROR cause a
crash, but I think I'd like to keep it that way.  I've tried very hard
to keep things like this consistent across different collections.  In
SmallTalk 'nil' is a valid element of many collections; whenever
possible, I'd like that to be true of libcoll also.  Although in
libcoll 'nil' can't be an element of LinkedList, it can be in Array,
Dictionary, etc.  I don't want some collections to return nil when
they really mean there are no more elements, and some other
collections not.

* While programming with libcoll I would write something like this,
instead of using 'withElementsCallUntilTrue:'.

{
  int result;
  BOOL flag = YES;
  void doit(elt e)
    {
      if ((result = testfunc(e)))
        flag = NO;
    }
  [aColl withElementsCall:doit whileTrue:flag];
  return result;
}

It seems more flexible to keep the stopping condition and return value
separate.  Your proposed withElementsCallUntilTrue gives special
meaning to 'nil'; again, just as with my last point, I'd rather not do
this. 

* I fully agree that some reference counting implementation will be
necessary.  You make an excellent argument for it and make many good
points.  Eventually it *will* happen; I'm just trying to think about
it carefully w.r.t. archiving, remote objects, etc.

* I'm looking forward to your KeyedSortedQueue; it sounds great!

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id MAA12342 for <mccallum>; Mon, 4 Jul 1994 12:29:14 -0400
Received: from mail2.netcom.com (mail2.netcom.com [192.100.81.122]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA24941 for <mccallum@cs.rochester.edu>; Mon, 4 Jul 1994 12:29:13 -0400
Received: from cayuga.cs.rochester.edu by mail2.netcom.com (8.6.8.1/Netcom)
	id JAA05657; Mon, 4 Jul 1994 09:26:55 -0700
From: mccallum@cs.rochester.edu
Received: from slate.cs.rochester.edu (slate.cs.rochester.edu [192.5.53.101]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA24910; Mon, 4 Jul 1994 12:20:44 -0400
Received: from vein.cs.rochester.edu (vein.cs.rochester.edu [192.5.53.112]) by slate.cs.rochester.edu (8.6.9/G) with SMTP id MAA12100; Mon, 4 Jul 1994 12:20:43 -0400
Message-Id: <199407041620.MAA12100@slate.cs.rochester.edu>
To: gnustep-l@netcom.com, gnu-objc@gnu.ai.mit.edu
Subject: News from the author of `libcoll'
Date: Mon, 04 Jul 94 12:20:42 -0400

Two items of news:

1) I'm working on an implementation of distributed objects.  I aim to
make it as compatible with OpenStep as I can.  Much progress has
already been made.  Don't ask me yet about a completion date.

2) Libcoll is changing its name to `libgobjc'.  Libcoll is growing,
and several of the new classes are not collection-type classes.  I
think the time has come for the GNU Objective-C community to have a
gathering place for general purpose, non-GUI classes, just like the
GNU C++ community has.  In this sense `libgobjc' will become to GNU
Objective-C what `libg++' is to GNU C++.  Richard Stallman and
Geoffrey Knauth have already given their go-ahead.

Libgobjc already contains the libcoll collection classes, as well as a
family of random number generators, classes for handling
time/magnitude, and the not-yet-finished distrubuted objects
implementation.

Just as libcoll contained NEXTSTEP-compatible collection classes,
(List, HashTable, NXStringTable), I plan to include the
OpenStep-compatible Foundation Classes in libgobjc.  This is analagous
to the inclusion of AT&T-compatible IO stream classes in libg++.

I am very open to the inclusion of your own general-purpose classes,
your implementations of OpenStep Foundation classes, and your
comments.  

Thanks for all your support!

Regards,
	Andrew

R. Andrew McCallum          EBOX: mccallum@cs.rochester.edu
Computer Science Dept       VOX: (716) 275-2527, (716) 275-1372 (lab)
University of Rochester     FAX: (716) 461-2018
Rochester, NY  14627-0226   http://www.cs.rochester.edu/u/mccallum

From 
Return-Path: gsk@marble.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id MAA13310 for <mccallum>; Mon, 4 Jul 1994 12:54:40 -0400
Received: from carrara.bos.marble.com (carrara.bos.marble.com [140.186.72.1]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id MAA25074 for <mccallum@cs.rochester.edu>; Mon, 4 Jul 1994 12:54:38 -0400
Received: from istrian.bos.marble.com.marble.com (istrian.bos.marble.com) by carrara.bos.marble.com with SMTP id AA23134
  (5.65c/IDA-1.4.4 for <mccallum@cs.rochester.edu>); Mon, 4 Jul 1994 12:51:13 -0400
Date: Mon, 4 Jul 1994 12:51:13 -0400
From: "Geoffrey S. Knauth" <gsk@marble.com>
Message-Id: <199407041651.AA23134@carrara.bos.marble.com>
Received: by istrian.bos.marble.com.marble.com (4.1/SMI-4.1)
	id AA03338; Mon, 4 Jul 94 12:51:11 EDT
To: mccallum@cs.rochester.edu
In-Reply-To: <199407041620.MAA12100@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: News from the author of `libcoll'

Andrew,
  Awesome news!  Way to go!
Geoffrey

From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id MAA12641 for <mccallum>; Mon, 4 Jul 1994 12:38:24 -0400
Received: from SERV02.SLAC.STANFORD.EDU (SERV02.SLAC.Stanford.EDU [134.79.16.10]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA25006 for <mccallum@cs.rochester.edu>; Mon, 4 Jul 1994 12:38:22 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU
 (PMDF V4.3-8 #6987) id <01HEAY7MAZ8G000ETY@SERV02.SLAC.STANFORD.EDU>; Mon,
 04 Jul 1994 09:38:08 -0700 (PDT)
Received: by kaon.SLAC.Stanford.EDU (NX5.67e/NX3.0S) id AA26531; Mon,
 4 Jul 94 09:37:53 -0700
Received: by NeXT.Mailer (1.100.RR)
Received: by NeXT Mailer (1.100.RR)
Date: Mon, 04 Jul 1994 09:37:53 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: Re: News from the author of `libcoll'
To: mccallum@cs.rochester.edu
Reply-to: Paul_Kunz@SLAC.Stanford.EDU
Message-id: <9407041637.AA26531@kaon.SLAC.Stanford.EDU>
X-Envelope-to: mccallum@cs.rochester.edu
Content-transfer-encoding: 7BIT

   Distributed Objects!   Great news.

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id SAA05482 for <mccallum>; Tue, 5 Jul 1994 18:41:58 -0400
Received: from mail2.netcom.com (mail2.netcom.com [192.100.81.122]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id SAA01849 for <mccallum@cs.rochester.edu>; Tue, 5 Jul 1994 18:41:56 -0400
Received: from cayuga.cs.rochester.edu by mail2.netcom.com (8.6.8.1/Netcom)
	id PAA06059; Tue, 5 Jul 1994 15:37:36 -0700
From: mccallum@cs.rochester.edu
Received: from slate.cs.rochester.edu (slate.cs.rochester.edu [192.5.53.101]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id SAA01842; Tue, 5 Jul 1994 18:35:37 -0400
Received: from vein.cs.rochester.edu (vein.cs.rochester.edu [192.5.53.112]) by slate.cs.rochester.edu (8.6.9/G) with SMTP id SAA05388; Tue, 5 Jul 1994 18:35:36 -0400
Message-Id: <199407052235.SAA05388@slate.cs.rochester.edu>
To: ratlifc@ctron.com (Christian A. Ratliff)
cc: gnustep-l@netcom.com
Subject: Re: objcX-0.8 
In-reply-to: Your message of "Tue, 05 Jul 94 16:00:31 EDT."
             <9407052000.AA24274@indikos> 
Date: Tue, 05 Jul 94 18:35:35 -0400

"Christian A. Ratliff" <ratlifc@indikos.ctron.com> writes:
>   When are we going to stop having our own libcoll? I use libcoll for 
> several other projects and rebuilding it all the time is tedious. I'm sure 
> Mr. McCallum would have put in those patches by now [unless I'm not privy 
> to some dispute about the nature of the patches].

There are no disputes.  In fact, I think Paul Kunz and I are a little
mutual admiration society. :-)

I'm willing to do whatever makes things easiest for people.  I do,
however, need someone who is more involved with objcX to let me know
exactly what need changes (in addition to bug fixes) are needed.  I
don't have the time right now to get deeply involved in objcX.

In the past, I've made a point NOT to post new snapshots for every
little bug fix---I didn't think people wanted to re-ftp and re-compile
that often.  But, if you like, that can change.  It's no problem for
me: I can provide new snapshots as fast as I can type "make dist".
In fact, ftp://ftp.cs.rochester.edu/pub/objc/libcoll-940705.tar.gz is
now available.  I has a few little bug fixes.

As I announced on this mailing list earlier, libcoll will be changing
its name to libgobjc, and will eventually contain the GNU version of
the OpenStep Foundation Kit.  Sometime this summer there will be a
first release of libgobjc, and from that point on there will be no new
releases of libcoll.  The objcX developers and I will have to
coordinate on some of details of this.

From 
Return-Path: fog@cyberspace.org
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id EAA17519 for <mccallum>; Wed, 6 Jul 1994 04:44:26 -0400
Received: from grex.cyberspace.org (root@grex.cyberspace.org [152.160.30.1]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id EAA03845 for <mccallum@cs.rochester.edu>; Wed, 6 Jul 1994 04:44:20 -0400
Received: by grex.cyberspace.org (Smail3.1.28.1 #4)
	id m0qLSaE-0001bLC; Wed, 6 Jul 94 04:43 EDT
Date: Wed, 6 Jul 1994 04:32:45 -0400 (EDT)
From: Federico Di Gregorio <fog@grex.cyberspace.org>
Subject: Greetings from the only libcoll-Amiga user in the world.
To: Andrew McCallum <mccallum@cs.rochester.edu>
Message-ID: <Pine.3.07.9407060445.A6635-a100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Or is that a little bit exagerated? Anyway is really hard to find other
ObjC users on the Amiga system...

I downloaded libcoll some week ago and... you did a great work, I written
only to say you that: really a great work!

The configure script didn't work all right on the Amiga, and the texinfo
file is a little bit incompatible with the Amiga version of MakeInfo
(AmigaGuide format much better that Info :).
I corrected the configure, but I don't know what to do for the docs (apart
from eliminating all the extra commands from the file).

Any sufggestion?

Federico Di Gregorio


From 
Return-Path: Paul_Kunz@SLAC.Stanford.EDU
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id KAA27447 for <mccallum>; Wed, 6 Jul 1994 10:54:51 -0400
Received: from SERV02.SLAC.STANFORD.EDU (SERV02.SLAC.Stanford.EDU [134.79.16.10]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id KAA04919 for <mccallum@cs.rochester.edu>; Wed, 6 Jul 1994 10:54:48 -0400
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU
 (PMDF V4.3-8 #6987) id <01HEDN59M2EO000JZX@SERV02.SLAC.STANFORD.EDU>; Wed,
 06 Jul 1994 07:54:02 -0700 (PDT)
Received: by kaon.SLAC.Stanford.EDU (NX5.67e/NX3.0S) id AA24299; Wed,
 6 Jul 94 07:53:46 -0700
Date: Wed, 06 Jul 1994 07:53:46 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: Re: objcX-0.8
In-reply-to: <199407061418.KAA26357@slate.cs.rochester.edu>
 (mccallum@cs.rochester.edu)
To: mccallum@cs.rochester.edu
Cc: ratlifc@ctron.com
Reply-to: Paul_Kunz@SLAC.Stanford.EDU
Message-id: <9407061453.AA24299@kaon.SLAC.Stanford.EDU>
X-Envelope-to: mccallum@cs.rochester.edu
Content-transfer-encoding: 7BIT

>>>>> On Wed, 06 Jul 1994 10:18:20 -0400, mccallum@cs.rochester.edu said:

> Am I missing something?  The default CFLAGS in the libcoll Makefile
> already includes -g.  What's the problem?

  True.

   I guess the real problem for me is not just steping thru libcoll
objects with gdb, but being able to try to fix the bugs and test them
quickly.  Even if libcoll is compiled with -g in /usr/local, I don't
want for each iteration in my attempts to fix bugs to compile into
/usr/local.  At SLAC, we have one master /usr/local shared by 262
machines and maintainence of software there is done with special
accounts.   Basically, I'm assuming that a developer of objcX might
not have the priveleges to maintain libobjc or libcoll at his site (I
don't at mine).

   Another reason is version control.  I import libcoll into CVS as a
"vendor" branch.  Any local fixes are on the main trunk.  With each
subsequent release of libcoll, I import and merge.  In this way I can
easily check that local fixes got incorporated in the release.  I
caught the one fix I submitted that was accidently omitted this way.

   I agree that there are some inconveniences in building libobjc and
libcoll alongside objcX.   You two might have more UNIX experience
then I since I've been mostly protected from UNIX by NeXTSTEP.   So
I'm open to suggestions on how to handle these two points better.


P.S.

   Keep in mind, that if something like -setContentView: is broken in
Box because of bug in List, then objcX is broken.   So that's why I
distribute libcoll with objcX.   It is saying: "this is the version of
libcoll we tested objcX with.  It should be the same as the official
release, but is here just in case".

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA14037 for <mccallum>; Thu, 14 Jul 1994 15:34:05 -0400
Received: from mail2.netcom.com (mail2.netcom.com [192.100.81.122]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id PAA17125 for <mccallum@cs.rochester.edu>; Thu, 14 Jul 1994 15:33:56 -0400
Received: from boulder.Colorado.EDU by mail2.netcom.com (8.6.8.1/Netcom)
	id MAA23896; Thu, 14 Jul 1994 12:29:37 -0700
Received: from mode.colorado.edu (mode.Colorado.EDU [128.138.248.167]) by boulder.Colorado.EDU (8.6.9/8.6.9/UnixOps) with SMTP id NAA01234; Thu, 14 Jul 1994 13:27:22 -0600
Received: by mode.colorado.edu (cu.generic.890828)
Date: Thu, 14 Jul 1994 13:27:20 -0600 (MDT)
From: Adam Fedor <fedor@mode.Colorado.EDU>
Sender: Adam Fedor <fedor@mode.Colorado.EDU>
Reply-To: Adam Fedor <fedor@mode.Colorado.EDU>
Subject: Re: NSArray vs. NSMutableArray? 
To: Mark Stankus <mstankus@oba.UCSD.EDU>
Cc: gnustep-l@netcom.com, Gnu Objective-C <gnu-objc@prep.ai.mit.edu>
In-Reply-To: <9407141732.AA21649@oba.UCSD.EDU>
Message-Id: <Pine.3.89.9407141328.C17631-0100000@mode.Colorado.EDU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII



On Thu, 14 Jul 1994, Mark Stankus wrote:

> What is the current feeling about starting to program the
> foundation kit classes at this point? This would not require
> any interaction with motif and so I could help to some extent.
> 
> Should we make the foundation kit classes part of the 
> gcc distribution?
> 
Andrew McCallum (mccallum@cs.rochester.edu) had previously talked about 
putting the OpenStep-compatible Foundation class 
in the libgobjc library (formerly libcoll library), and just making 
libgobjc a place to put general purpose objects.  I'm sure he would be 
willing to accept help from anybody... 

Personally, I'm wondering how large libgobjc can get. You really 
need to include all the objects in a library, since in Objective-C you 
can never be sure which ones your going to use until runtime.  This could 
make for a huge program -- although at least NeXT and Sun can do shared 
libraries.

adam

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA14602 for <mccallum>; Thu, 14 Jul 1994 15:59:59 -0400
Received: from netcom.com (netcom4.netcom.com [192.100.81.107]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id PAA17276 for <mccallum@cs.rochester.edu>; Thu, 14 Jul 1994 15:59:55 -0400
Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom)
	id MAA08543; Thu, 14 Jul 1994 12:54:07 -0700
From: keith@netcom.com (Keith Mason)
Message-Id: <199407141954.MAA08543@netcom4.netcom.com>
Subject: Re: NSArray vs. NSMutableArray?
To: fedor@mode.Colorado.EDU
Date: Thu, 14 Jul 1994 12:54:07 -0700 (PDT)
Cc: gnustep-l@netcom.com, gnu-objc@prep.ai.mit.edu
In-Reply-To: <Pine.3.89.9407141328.C17631-0100000@mode.Colorado.EDU> from "Adam Fedor" at Jul 14, 94 01:27:20 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 705       

> Personally, I'm wondering how large libgobjc can get. You really 
> need to include all the objects in a library, since in Objective-C you 
> can never be sure which ones your going to use until runtime.  This could 
> make for a huge program -- although at least NeXT and Sun can do shared 
> libraries.
> 
> adam

I don't see any reason *we* can't use shared libraries.  The programmer
would just have to be aware of where the executable was going.  libgobjc
is likely going to be in a separate package (like g++ is), so if a
program is to be distributed, the programmer has the option of shipping
the shared lib with it, instructing the installer to install the lib,
or compiling static.

  -- Keith

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id SAA18496 for <mccallum>; Thu, 14 Jul 1994 18:21:38 -0400
Received: from mail.netcom.com (mail.netcom.com [192.100.81.99]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id SAA18119 for <mccallum@cs.rochester.edu>; Thu, 14 Jul 1994 18:21:31 -0400
Received: from mole.gnu.ai.mit.edu by mail.netcom.com (8.6.8.1/Netcom)
	id PAA13023; Thu, 14 Jul 1994 15:14:35 -0700
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA15429@mole.gnu.ai.mit.edu>; Thu, 14 Jul 94 18:11:15 -0400
Date: Thu, 14 Jul 94 18:11:15 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9407142211.AA15429@mole.gnu.ai.mit.edu>
To: fedor@mode.colorado.edu
Cc: mstankus@oba.ucsd.edu, gnustep-l@netcom.com, gnu-objc@prep.ai.mit.edu
In-Reply-To: <Pine.3.89.9407141328.C17631-0100000@mode.Colorado.EDU> (message from Adam Fedor on Thu, 14 Jul 1994 13:27:20 -0600 (MDT))
Subject: Re: NSArray vs. NSMutableArray?

I don't think that the size of the library is a big issue.
The maintainers can split it into multiple .a files if they wish.

GNU ld is going to have a feature that allows one umbrella library
to effectively consist of the sum total of several other libraries.
With that, any library can be split into multiple .a files, without
the user's having to notice.

Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id SAA19115 for <mccallum>; Thu, 14 Jul 1994 18:45:12 -0400
Received: from netcom.com (netcom8.netcom.com [192.100.81.117]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id SAA18214 for <mccallum@cs.rochester.edu>; Thu, 14 Jul 1994 18:45:09 -0400
Received: from awatovi by netcom.com (8.6.8.1/SMI-4.1/Netcom)
	id PAA27752; Thu, 14 Jul 1994 15:33:42 -0700
From: nelson@santafe.edu
Received: by awatovi (4.1/SMI-4.1)
	id AA04261; Thu, 14 Jul 94 16:30:13 MDT
Date: Thu, 14 Jul 94 16:30:13 MDT
Message-Id: <9407142230.AA04261@awatovi>
To: gnustep-l@netcom.com, gnu-objc@prep.ai.mit.edu
Subject: Re: NSArray vs. NSMutableArray?
In-Reply-To: <199407141954.MAA08543@netcom4.netcom.com>
References: <Pine.3.89.9407141328.C17631-0100000@mode.Colorado.EDU>
	<199407141954.MAA08543@netcom4.netcom.com>

(is the gnu-objc list active? My requests to subscribe have not been
answered).

on the question of the size of libgobjc:

>I don't see any reason *we* can't use shared libraries.  The programmer
>would just have to be aware of where the executable was going.

And the operating system has to support shared libraries. I hate to
say it, but at least one major UNIX (Ultrix) doesn't support shared
libraries, nor will it anytime soon. Ultrix folks are used to having
200 copies of libXaw around in their X binary directory, so this would
just be one more bloat, but it's something to keep in mind.

Is there some reason libgobjc couldn't be split into several smaller
libraries? The runtime library is already different from the
collection class.. I could imagine making the GUI, the distributed
objects library, and the collections all seperate libraries.

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id MAA12876 for <mccallum>; Sat, 16 Jul 1994 12:43:18 -0400
Received: from mail2.netcom.com (mail2.netcom.com [192.100.81.122]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA26576 for <mccallum@cs.rochester.edu>; Sat, 16 Jul 1994 12:43:16 -0400
Received: from mole.gnu.ai.mit.edu by mail2.netcom.com (8.6.8.1/Netcom)
	id JAA03248; Sat, 16 Jul 1994 09:42:23 -0700
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09931@mole.gnu.ai.mit.edu>; Sat, 16 Jul 94 12:41:54 -0400
Date: Sat, 16 Jul 94 12:41:54 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9407161641.AA09931@mole.gnu.ai.mit.edu>
To: keith@netcom.com
Cc: gnustep-l@netcom.com, gnu-objc@prep.ai.mit.edu
In-Reply-To: <199407160750.AAA02421@netcom3.netcom.com> (keith@netcom.com)
Subject: Re: NSArray vs. NSMutableArray?

Thanks for explaining these details about categories.

It might be useful to have some additional feature for causing
categories to be linked in from a library.  But I don't think users
would be very happy if this feature unconditionally linked in
every category that GNU Objective C library provides.

For one thing, that would make every program executable get bigger and
bigger as new features are added to the library.

Shared libraries avoid that problem on some systems, but they don't
solve a second problem: namespace pollution.  This approach would
require users to avoid defining names that the library defines, which
would be quite unpleasant since the library will define more and more
names as features are added to it.

Whatever users do to include library categories in their programs, it
must be selective.

I can see two reasonable alternatives: 

* Provide many separate library files, each of which is defined to
supply a particular category or a few closely related categories.
Arrange for each of these files to force linking of those categories.
Then the users can specify which categories they want by naming these
files.

This has the merit of requiring no new linker features.

* Provide a new feature that lets the user easily specify "link in the
category named foo".

There may be other reasonable alternatives.

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id MAA13030 for <mccallum>; Sat, 16 Jul 1994 12:46:36 -0400
Received: from mail2.netcom.com (mail2.netcom.com [192.100.81.122]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA26582 for <mccallum@cs.rochester.edu>; Sat, 16 Jul 1994 12:46:34 -0400
Received: from mole.gnu.ai.mit.edu by mail2.netcom.com (8.6.8.1/Netcom)
	id JAA03460; Sat, 16 Jul 1994 09:46:15 -0700
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09965@mole.gnu.ai.mit.edu>; Sat, 16 Jul 94 12:45:48 -0400
Date: Sat, 16 Jul 94 12:45:48 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9407161645.AA09965@mole.gnu.ai.mit.edu>
To: keith@netcom.com
Cc: gnustep-l@netcom.com, gnu-objc@prep.ai.mit.edu
In-Reply-To: <199407160750.AAA02421@netcom3.netcom.com> (keith@netcom.com)
Subject: Re: NSArray vs. NSMutableArray?

People might be surprised by the statement that a library file can
force the linking of its contents, without any new linker features.

There's no way that an archive file can do this.  However, a library
file need not be an archive.  It can be an object file.  If you
specify -lfoo, and libfoo.a happens to be an object file, then it is
linked unconditionally.

If the contents of a library consist of a category and its methods and
associated other things, then it must be either entirely included or
entirely excluded.  There's nothing to gain from subdividing it into
parts.  It could just as well be a single object file.

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id QAA07486 for <mccallum>; Sun, 17 Jul 1994 16:48:33 -0400
Received: from mail.netcom.com (mail.netcom.com [192.100.81.99]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id QAA29588 for <mccallum@cs.rochester.edu>; Sun, 17 Jul 1994 16:48:30 -0400
Received: from SERV02.SLAC.STANFORD.EDU by mail.netcom.com (8.6.8.1/Netcom)
	id NAA07554; Sun, 17 Jul 1994 13:46:05 -0700
Received: from kaon.SLAC.Stanford.EDU by SERV02.SLAC.STANFORD.EDU
 (PMDF V4.3-8 #6987) id <01HETCLPKWUO0015AR@SERV02.SLAC.STANFORD.EDU>; Sun,
 17 Jul 1994 13:44:39 -0700 (PDT)
Received: by kaon.SLAC.Stanford.EDU (NX5.67e/NX3.0S) id AA10879; Sun,
 17 Jul 94 13:44:28 -0700
Received: by NeXT.Mailer (1.100.RR)
Received: by NeXT Mailer (1.100.RR)
Date: Sun, 17 Jul 1994 13:44:28 -0700
From: "Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU>
Subject: Archiving/Unarchiving
To: gnustep-l@netcom.com
Reply-to: Paul_Kunz@SLAC.Stanford.EDU
Message-id: <9407172044.AA10879@kaon.SLAC.Stanford.EDU>
X-Envelope-to: gnustep-l@netcom.com
Content-transfer-encoding: 7BIT

   As part of the application (HippoDraw) we're porting to X windows  
using objcX, we need to archiving/unarchive a drawing document.   The  
NeXTSTEP application uses NeXT's typedstreams on the list of objects in  
the document.   I need to write files that are portable and re-write  
the NeXTSTEP application to use them as well.
   

   I considered using GNU archiving but it is messy to mix NeXT and GNU  
archiving in the same program (cf. nib-translator) and it doesn't  
support floats.
   

   Long before we had idea to do objcX, we considered archiving the  
document in ASCII form so it could be human readable and editable.    
Now, I believe OpenStep archiving does exactly that.  Therefore, it  
would seem to make sense to just write and use OpenStep archiving.
   

   Does anybody have thoughts on these questions:
   

- does this make sense?
- does anybody have similar problem to mine and how to your solve it?
- does anybody example of code that shows how OpenStep archiving works?
- what is the format of the archive file?
- any other related thoughts?

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id RAA09121 for <mccallum>; Sun, 17 Jul 1994 17:41:00 -0400
Received: from netcom.com (root@netcom7.netcom.com [192.100.81.115]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id RAA29676 for <mccallum@cs.rochester.edu>; Sun, 17 Jul 1994 17:40:58 -0400
Received: from lighthouse.com by netcom.com (8.6.8.1/SMI-4.1/Netcom)
	id OAA06731; Sun, 17 Jul 1994 14:38:11 -0700
Received: from buffalo by lighthouse.com (NX5.67e/NeXT-2.0)
	id AA25109; Sun, 17 Jul 94 14:42:28 -0700
From: garrick@lighthouse.com (Garrick Toubassi)
Message-Id: <9407172142.AA25109@lighthouse.com>
Received: by buffalo (NX5.67d/NX3.0X)
	id AA25070; Sun, 17 Jul 94 14:42:26 -0700
Date: Sun, 17 Jul 94 14:42:26 -0700
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Paul_Kunz@SLAC.Stanford.EDU
Subject: Re: Archiving/Unarchiving
Cc: gnustep-l@netcom.com

At Lighthouse, we have chosen ASCII archiving for exactly the reasons you  
mentioned (easier to recover corrupted docs, easier to generate docs from other  
apps or scripts, human readable).  It is also much much easier to debug, and is  
much easier to maintain compatibility across major revisions of the app  
(because the archive is no longer typed to specific classes).

I do not know much about the new OpenStep text archiving, but I believe it all  
goes through the NSDictionary, and the format is a bunch of key value pairs  
like the ones found in the data.classes file of a .nib.

One downside to watch out for is potential bloating of the files.  For instance  
in NeXT object archiving and int takes 5 bytes (1 for the type and 4 for the  
data, I believe), while if you write it out in ascii as a key value pair (eg  
"StartPageNumber = 3;" you will take up much more space.

Overall, though, I think its the way to go in order to keep from revisiting the  
same problem over and over again.

I too would be interested in seeing example code

garrick

From 
To: gnu-objc@prep.ai.mit.edu
Subject: libgobjc name prefix
Date: Fri, 05 Aug 94 14:37:01 -0400
From: mccallum@cs.rochester.edu

I have almost finished making the necessary adjustments for changing
the name of libcoll to "libgobjc".  I think that this time of
renaming would be an opportune moment to resolve the issue of a prefix
for the public names in the library.

The GNU coding standards say that all external function and variable
names in a library should start with a prefix.  For example, the all
the functions in libbfd begin with "bfd_", etc.

Libg++ is an interesting exception to this rule.  It does not have a
prefix.  Can anyone tell me why?

Without a prefix, libgobjc will use such dangerously common names as:
Array, Heap, Dictionary and Random.

I propose to prefix all function and variable names with "gobjc_", and
to prefix all class names with "GO".  The NeXT-compatible names will,
of course, remain as is to preserve compatibility.

Any comments for or against the proposal?

From 
Return-Path: gsk@marble.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA17664 for <mccallum>; Fri, 5 Aug 1994 15:20:16 -0400
Received: from carrara.bos.marble.com (carrara.bos.marble.com [140.186.72.1]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id PAA10451 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 15:20:14 -0400
Received: from istrian.bos.marble.com.marble.com (istrian.bos.marble.com) by carrara.bos.marble.com with SMTP id AA08970
  (5.65c/IDA-1.4.4 for <mccallum@cs.rochester.edu>); Fri, 5 Aug 1994 15:16:19 -0400
Date: Fri, 5 Aug 1994 15:16:19 -0400
From: "Geoffrey S. Knauth" <gsk@marble.com>
Message-Id: <199408051916.AA08970@carrara.bos.marble.com>
Received: by istrian.bos.marble.com.marble.com (4.1/SMI-4.1)
	id AA01195; Fri, 5 Aug 94 15:16:18 EDT
To: mccallum@cs.rochester.edu
In-Reply-To: <199408051837.OAA16293@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

I'm not sure if "GO" is the prefix I would have picked, but the
idea of having a standard prefix makes sense.

  Maybe "GO" is OK, if you think of the Japanese game of GO, with its
pre-eminent sophistication.

Geoffrey

From 
Replied: Fri, 05 Aug 94 15:42:20 -0400
Replied: "Per Bothner <bothner@cygnus.com> "
Return-Path: bothner@cygnus.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA18234 for <mccallum>; Fri, 5 Aug 1994 15:33:19 -0400
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id PAA10537 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 15:33:17 -0400
Received: from cygnus.com by relay1.UU.NET with ESMTP 
	id QQxbri22799; Fri, 5 Aug 1994 15:33:13 -0400
Received: from kalessin.cygnus.com (kalessin.cygnus.com [140.174.1.93]) by cygnus.com (8.6.9/8.6.9) with ESMTP id MAA22065; Fri, 5 Aug 1994 12:33:10 -0700
From: Per Bothner <bothner@cygnus.com>
Received: from localhost (bothner@localhost) by kalessin.cygnus.com (8.6.4/8.6.4) id MAA07756; Fri, 5 Aug 1994 12:33:49 -0700
Message-Id: <199408051933.MAA07756@kalessin.cygnus.com>
To: "D. V. Henkel-Wallace" <gumby@cygnus.com>, mccallum@cs.rochester.edu
cc: gnu-objc@prep.ai.mit.edu
Subject: Re: [mccallum@cs.rochester.edu: libgobjc name prefix] 
In-reply-to: (Your message of Fri, 05 Aug 94 12:21:07 MST.)
             <199408051921.MAA23033@mexican.cygnus.com> 
Date: Fri, 05 Aug 94 12:33:48 -0800

> Libg++ is an interesting exception to this rule.  It does not have a
> prefix.  Can anyone tell me why?

C++ function names are less likely to clash because of overloading
and name mangling (the compiler encodes the parameter types
into the assembler-label of the function).

The ANSI/ISO C++ draft includes a "namespace" mechanism.
It is the intent that all libraries (standard and special)
be in different name spaces.  (E.g. if bdf were re-written in
C++, if would be in a "bfd" namespace.)  Namespaces are not
yet implemented in g++, we are also missing many of the
pieces of the standard library, and the standard is still
evolving, but we will probably clean this up within a year's time.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

From 
To: Per Bothner <bothner@cygnus.com>
Subject: Re: [mccallum@cs.rochester.edu: libgobjc name prefix] 
In-reply-to: Your message of "Fri, 05 Aug 94 12:33:48 -0800."
             <199408051933.MAA07756@kalessin.cygnus.com> 
Date: Fri, 05 Aug 94 15:42:20 -0400
From: mccallum@cs.rochester.edu

Per Bothner <bothner@cygnus.com> writes:
> The ANSI/ISO C++ draft includes a "namespace" mechanism.
> It is the intent that all libraries (standard and special)
> be in different name spaces.  (E.g. if bdf were re-written in
> C++, if would be in a "bfd" namespace.)  Namespaces are not
> yet implemented in g++, we are also missing many of the
> pieces of the standard library, and the standard is still
> evolving, but we will probably clean this up within a year's time.

Just curious:  Is this a recommendation not to prefix the names?

If this namespace mechanism will be incorporated into Objective-C, I
would prefer to use it instead of prefixing.  I'm worried, however,
about what it would be like for developers during the year before it
was available.

From 
Return-Path: bothner@cygnus.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id QAA19068 for <mccallum>; Fri, 5 Aug 1994 16:05:16 -0400
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id QAA10749 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 16:05:14 -0400
Received: from cygnus.com by relay1.UU.NET with ESMTP 
	id QQxbrk00964; Fri, 5 Aug 1994 16:05:07 -0400
Received: from kalessin.cygnus.com (kalessin.cygnus.com [140.174.1.93]) by cygnus.com (8.6.9/8.6.9) with ESMTP id NAA22966 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 13:05:06 -0700
From: Per Bothner <bothner@cygnus.com>
Received: from localhost (bothner@localhost) by kalessin.cygnus.com (8.6.4/8.6.4) id NAA28777; Fri, 5 Aug 1994 13:06:00 -0700
Message-Id: <199408052006.NAA28777@kalessin.cygnus.com>
To: mccallum@cs.rochester.edu
Subject: Re: [mccallum@cs.rochester.edu: libgobjc name prefix] 
In-reply-to: (Your message of Fri, 05 Aug 94 15:42:20 D.)
             <199408051942.PAA18465@slate.cs.rochester.edu> 
Date: Fri, 05 Aug 94 13:05:59 -0800

> Is this a recommendation not to prefix the names?

Yes, but only in the case of C++.

> If this namespace mechanism will be incorporated into Objective-C,

I doubt it.  That would be up to the Objective-C people.
It would be nice if we could make C++ namespaces, Ada packages,
Modula-3 modules, and some similar Objective-C concept compatible.
We will try to a least not make them gratuitously incompatible.

> I'm worried, however,
> about what it would be like for developers during the year before it
> was available.

No worse than it has been for all the preceding years.

	--Per Bothner
Cygnus Support     bothner@cygnus.com


From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id SAA24393 for <mccallum>; Fri, 5 Aug 1994 18:29:29 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id SAA11536 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 18:29:27 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09077@mole.gnu.ai.mit.edu>; Fri, 5 Aug 94 18:29:24 -0400
Date: Fri, 5 Aug 94 18:29:24 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408052229.AA09077@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408051837.OAA16293@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

Please eliminate the word "GNU" from the name and call it just libobjc.
We don't want all the programs on the GNU system to start with `g'.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id SAA24631 for <mccallum>; Fri, 5 Aug 1994 18:35:39 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id SAA11559 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 18:35:37 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09094@mole.gnu.ai.mit.edu>; Fri, 5 Aug 94 18:35:26 -0400
Date: Fri, 5 Aug 94 18:35:26 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408052235.AA09094@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408051837.OAA16293@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    Libg++ is an interesting exception to this rule.  It does not have a
    prefix.

Such a library is not one single package, but a collection of
unrelated packages.

It makes sense for most such packages, individually, to have prefixes
for their names.  These prefixes should be independent.  It would be
just a nuisance to make all the prefixes have a prefix for the whole
library.

In a class-oriented language such as Objective C, a package which
defines a class should usually use the class name as the prefix
for any other names it defines.

From 
To: rms@gnu.ai.mit.edu (Richard Stallman)
CC: gnu-objc@prep.ai.mit.edu
Subject: Re: libgobjc name prefix 
In-reply-to: Your message of "Fri, 05 Aug 94 18:29:24 EDT."
             <9408052229.AA09077@mole.gnu.ai.mit.edu> 
Date: Fri, 05 Aug 94 18:46:07 -0400
From: mccallum@cs.rochester.edu

rms@gnu.ai.mit.edu (Richard Stallman) writes:
> Please eliminate the word "GNU" from the name and call it just libobjc.
> We don't want all the programs on the GNU system to start with `g'.

libobjc already exists and is part of gcc.  Are you suggesting merging
the two libraries?

This isn't necessarily a bad idea, but we should consider it
carefully.  The administrative change would be non-trivial, and I'm
not sure we should force everyone using the GNU Objective-C runtime to
also use this class library.

Perhaps we could rename the current Objective-C runtime library from
"libobjc" to "libobjcrun" and name the class library "libobjc", as you
suggest.  I also think that we should configure gcc to automatically
link with libobjcrun when compiling Objective-C code.

From 
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: libgobjc name prefix 
In-reply-to: Your message of "Fri, 05 Aug 94 18:35:26 EDT."
             <9408052235.AA09094@mole.gnu.ai.mit.edu> 
Date: Fri, 05 Aug 94 18:58:26 -0400
From: mccallum@cs.rochester.edu

rms@gnu.ai.mit.edu (Richard Stallman) writes:
> In a class-oriented language such as Objective C, a package which
> defines a class should usually use the class name as the prefix
> for any other names it defines.

Yes, but what about the class names themselves that may conflict with
names the programmer wanted to use (or are used by other packages,
such as X's use of "Object", or the SGI graphics library's use of
"Matrix").

I'm a little uncertain what you are proposing.  Are you suggesting
changing the name of the class "Array" or leaving it as is?  I'm
concerned about leaving it.  If you suggest changing it, what are you
suggesting?

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id UAA28962 for <mccallum>; Fri, 5 Aug 1994 20:29:40 -0400
Received: from netcom6.netcom.com (keith@netcom6.netcom.com [192.100.81.114]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id UAA11954 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 20:29:37 -0400
Received: by netcom6.netcom.com (8.6.8.1/Netcom)
	id RAA02943; Fri, 5 Aug 1994 17:29:33 -0700
From: keith@netcom.com (Keith Mason)
Message-Id: <199408060029.RAA02943@netcom6.netcom.com>
Subject: Re: libgobjc name prefix
To: mccallum@cs.rochester.edu
Date: Fri, 5 Aug 1994 17:29:30 -0700 (PDT)
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408052246.SAA24957@slate.cs.rochester.edu> from "mccallum@cs.rochester.edu" at Aug 5, 94 06:46:07 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1398      

> 
> rms@gnu.ai.mit.edu (Richard Stallman) writes:
> > Please eliminate the word "GNU" from the name and call it just libobjc.
> > We don't want all the programs on the GNU system to start with `g'.
> 
> libobjc already exists and is part of gcc.  Are you suggesting merging
> the two libraries?
> 
> This isn't necessarily a bad idea, but we should consider it
> carefully.  The administrative change would be non-trivial, and I'm
> not sure we should force everyone using the GNU Objective-C runtime to
> also use this class library.
> 
> Perhaps we could rename the current Objective-C runtime library from
> "libobjc" to "libobjcrun" and name the class library "libobjc", as you
> suggest.  I also think that we should configure gcc to automatically
> link with libobjcrun when compiling Objective-C code.
> 

I disagree.  Merging the libraries could be a very bad idea, for just the
reason you give above.  I don't see anything wrong with leaving the "g"
there... we have Gcc, G++, libG++, libGcc, and that's just the language
programs.  Other software, like GhostScript, have used the "g" to identify
it as being GNU.  Why change the pattern now?  This is very much a GNU
specific library (unlike the runtime, which works under the same model
as other Obj-C runtimes).

Besides, I find it easier to identify software that's GNU by looking for
*g* in my directories sometimes. :-)

  -- Keith

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id VAA00574; Fri, 5 Aug 1994 21:04:49 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id VAA12076; Fri, 5 Aug 1994 21:04:46 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA00535@albert.gnu.ai.mit.edu>; Fri, 5 Aug 94 20:20:18 -0400
Received: from netcom6.netcom.com by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA13181; Fri, 5 Aug 94 20:20:09 EDT
Received: by netcom6.netcom.com (8.6.8.1/Netcom)
	id RAA01744; Fri, 5 Aug 1994 17:20:26 -0700
From: keith@netcom.com (Keith Mason)
Message-Id: <199408060020.RAA01744@netcom6.netcom.com>
Subject: Re: libgobjc name prefix
To: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Fri, 5 Aug 1994 17:20:25 -0700 (PDT)
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <9408052235.AA09094@mole.gnu.ai.mit.edu> from "Richard Stallman" at Aug 5, 94 06:35:26 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 873       

RMS writes:
> In a class-oriented language such as Objective C, a package which
> defines a class should usually use the class name as the prefix
> for any other names it defines.

Since the class name must have a prefix of its own, wouldn't it make
more sense to use a prefix that went on both the class name and also
any globals associated with it?

What besides the class name is there, anyway, that can be made global
in a class library?  Category names have their own namespace, which
is independent of other classes as well (ie, category "foo" for class
"Object" is independent of category "foo" of class "List").  Protocol
names work the same way.  The only thing that might be global would
be variables for the library, which really should be kept internal,
anyway.  Everything should be accessible through class methods; nothing
should be made global.

  -- Keith

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id WAA05231 for <mccallum>; Fri, 5 Aug 1994 22:53:15 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id WAA12393 for <mccallum@cs.rochester.edu>; Fri, 5 Aug 1994 22:53:12 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09482@mole.gnu.ai.mit.edu>; Fri, 5 Aug 94 22:53:03 -0400
Date: Fri, 5 Aug 94 22:53:03 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408060253.AA09482@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408052258.SAA25351@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    I'm a little uncertain what you are proposing.  Are you suggesting
    changing the name of the class "Array" or leaving it as is?

If this is a very general sort of array feature that will be basic in
use in lots of programs, it is worth a name like `Array'.

From
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id XAA08246; Fri, 5 Aug 1994 23:49:23 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id XAA12504; Fri, 5 Aug 1994 23:49:20 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA02644@albert.gnu.ai.mit.edu>; Fri, 5 Aug 94 23:11:43 -0400
Received: from mole.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA23222; Fri, 5 Aug 94 23:11:40 EDT
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09540@mole.gnu.ai.mit.edu>; Fri, 5 Aug 94 23:11:10 -0400
Date: Fri, 5 Aug 94 23:11:10 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408060311.AA09540@mole.gnu.ai.mit.edu>
To: keith@netcom.com
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408060020.RAA01744@netcom6.netcom.com> (keith@netcom.com)
Subject: Re: libgobjc name prefix

    Since the class name must have a prefix of its own, wouldn't it make
    more sense to use a prefix that went on both the class name and also
    any globals associated with it?

I am not sure what you mean, but my best guess is you are suggesting
having a prefix we add to all class names.

I don't think we should do that, because these classes are
fundamental.  They are analogous to functions like `malloc' and `open'
in C.  Names that important *should not* have cumbersome prefixes.

Prefixes to avoid name conflicts make sense for obscure packages which
(1) not everyone knows about and (2) are used infrequently enough that
it matters little if their names are cumbersome.

From
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id XAA08283; Fri, 5 Aug 1994 23:50:59 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id XAA12514; Fri, 5 Aug 1994 23:50:57 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA02681@albert.gnu.ai.mit.edu>; Fri, 5 Aug 94 23:16:32 -0400
Received: from mole.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA23657; Fri, 5 Aug 94 23:16:30 EDT
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09554@mole.gnu.ai.mit.edu>; Fri, 5 Aug 94 23:16:29 -0400
Date: Fri, 5 Aug 94 23:16:29 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408060316.AA09554@mole.gnu.ai.mit.edu>
To: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408060020.RAA01744@netcom6.netcom.com> (keith@netcom.com)
Subject: Re: libgobjc name prefix

I recommend the practice of adding common prefixes to libraries in the
GNU coding standards because that is a good practice when writing
specialized libraries.

Most C libraries people write at this late date are specialized to a
particular purpose.  And usually the whole library exists for just one
purpose.  None of these libraries is *the principal library* for C.

The basic bag-of-tricks library for a language should not be treated
like a specialized library.  It is not specialized and it has no
single purpose.  It will be the principal user-visible library for GNU
Objective C.  It deserves to be an exception to the usual rules.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id AAA09079 for <mccallum>; Sat, 6 Aug 1994 00:05:36 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id AAA12563 for <mccallum@cs.rochester.edu>; Sat, 6 Aug 1994 00:05:29 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09751@mole.gnu.ai.mit.edu>; Sat, 6 Aug 94 00:04:33 -0400
Date: Sat, 6 Aug 94 00:04:33 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408060404.AA09751@mole.gnu.ai.mit.edu>
To: keith@netcom.com
Cc: mccallum@cs.rochester.edu, gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408060029.RAA02943@netcom6.netcom.com> (keith@netcom.com)
Subject: Re: libgobjc name prefix

In general I don't want to have a `g' at the beginning of more GNU
programs.  Please don't argue about it.  I've already made up my mind.
I expect that, no matter what decision I might make on such a question,
some people will disagree; therefore I expect some people to disagree
and I don't think it matters.

When you write a system, you can put a your favorite letter at the
beginning of the names of all the programs if you wish.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id BAA13404 for <mccallum>; Sat, 6 Aug 1994 01:17:57 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id BAA12788 for <mccallum@cs.rochester.edu>; Sat, 6 Aug 1994 01:17:55 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09896@mole.gnu.ai.mit.edu>; Sat, 6 Aug 94 01:17:47 -0400
Date: Sat, 6 Aug 94 01:17:47 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408060517.AA09896@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408052246.SAA24957@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    libobjc already exists and is part of gcc.  Are you suggesting merging
    the two libraries?

I'd forgotten that the name libobjc was already in use.  I wasn't
meaning to suggest merging these two libraries; there are reasons to
keep them separate.  Perhaps those reasons can be overcome and the
libraries could be merged, but that's not what I have in mind.

Since libobjc.a is not usable, let's choose some other name, not
libgobjc.a either.  I suggest libobjc-basic.a or libobjc-classes.a.
Perhaps those suggestions will inspire another idea that is even
better.

The main purpose of all GNU software is to be part of the GNU system.
On the GNU system, almost every program will be the GNU version of
this-or-that.  This will go without saying.  It would be silly, and
inconvenient for the users, to stick `g' onto the name of everything
in the system.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id BAA13444 for <mccallum>; Sat, 6 Aug 1994 01:19:03 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id BAA12796 for <mccallum@cs.rochester.edu>; Sat, 6 Aug 1994 01:19:02 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA09901@mole.gnu.ai.mit.edu>; Sat, 6 Aug 94 01:19:00 -0400
Date: Sat, 6 Aug 94 01:19:00 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408060519.AA09901@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408052246.SAA24957@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

      I also think that we should configure gcc to automatically
    link with libobjcrun when compiling Objective-C code.

That might be a reasonable idea, but I am not sure it is possible.
I don't think there's any way gcc can *tell* that some of the code was
written in Objective C.

It might be ok instead to link with libobjc.a always by default.


From 
Return-Path: gsk@marble.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id HAA16409; Sat, 6 Aug 1994 07:10:27 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id HAA13606; Sat, 6 Aug 1994 07:10:25 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA16399@albert.gnu.ai.mit.edu>; Sat, 6 Aug 94 06:17:52 -0400
Received: from carrara.bos.marble.com by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA04846; Sat, 6 Aug 94 06:17:45 EDT
Received: by carrara.bos.marble.com id AA20825
  (5.65c/IDA-1.4.4 for gnu-objc@prep.ai.mit.edu); Sat, 6 Aug 1994 06:13:47 -0400
Date: Sat, 6 Aug 1994 06:13:47 -0400
From: "Geoffrey S. Knauth" <gsk@marble.com>
Message-Id: <199408061013.AA20825@carrara.bos.marble.com>
To: gnu-objc@prep.ai.mit.edu
Subject: libobjcrun

> [mccallum@cs.rochester.edu replies to rms@gnu.ai.mit.edu]
> Perhaps we could rename the current Objective-C runtime library from
> "libobjc" to "libobjcrun" and name the class library "libobjc", as you
> suggest.  I also think that we should configure gcc to automatically

The runtime could also be renamed "libobjcrt".

Geoffrey

From 
Return-Path: keith@netcom.com
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id RAA02652; Sat, 6 Aug 1994 17:38:19 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id RAA14568; Sat, 6 Aug 1994 17:38:07 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA20295@albert.gnu.ai.mit.edu>; Sat, 6 Aug 94 16:59:54 -0400
Received: from netcom8.netcom.com by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA08318; Sat, 6 Aug 94 16:59:51 EDT
Received: by netcom8.netcom.com (8.6.8.1/Netcom)
	id OAA10332; Sat, 6 Aug 1994 14:00:01 -0700
From: keith@netcom.com (Keith Mason)
Message-Id: <199408062100.OAA10332@netcom8.netcom.com>
Subject: Re: libobjcrun
To: gsk@marble.com (Geoffrey S. Knauth)
Date: Sat, 6 Aug 1994 14:00:00 -0700 (PDT)
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408061013.AA20825@carrara.bos.marble.com> from "Geoffrey S. Knauth" at Aug 6, 94 06:13:47 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 620       

> > [mccallum@cs.rochester.edu replies to rms@gnu.ai.mit.edu]
> > Perhaps we could rename the current Objective-C runtime library from
> > "libobjc" to "libobjcrun" and name the class library "libobjc", as you
> > suggest.  I also think that we should configure gcc to automatically
> 
> The runtime could also be renamed "libobjcrt".

While it may be a good idea to rename the existing runtime, I also think
that using libobjc for Andrew's class kit would be a bad idea.  Is there
a name, other than Foundation Kit, that the library as a whole could be
given?  If so, we should use an abbreviation of that.

  -- Keith

From 
Return-Path: fedor@mode.colorado.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id VAA09388; Sat, 6 Aug 1994 21:16:26 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id VAA14924; Sat, 6 Aug 1994 21:16:24 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA21989@albert.gnu.ai.mit.edu>; Sat, 6 Aug 94 20:48:44 -0400
Received: from boulder.Colorado.EDU by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA11459; Sat, 6 Aug 94 20:48:41 EDT
Received: from mode.colorado.edu (mode.Colorado.EDU [128.138.248.167]) by boulder.Colorado.EDU (8.6.9/8.6.9/UnixOps) with SMTP id SAA06611 for <gnu-objc@prep.ai.mit.edu>; Sat, 6 Aug 1994 18:48:38 -0600
Received: by mode.colorado.edu (cu.generic.890828)
Date: Sat, 6 Aug 1994 18:48:35 -0600 (MDT)
From: Adam Fedor <fedor@mode.colorado.edu>
Subject: gnu-objc library names
To: gnu-objc@prep.ai.mit.edu
In-Reply-To: <199408062100.OAA10332@netcom8.netcom.com>
Message-Id: <Pine.3.89.9408061808.A22875-0100000@mode.Colorado.EDU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


How about the Objective-C Fundamentals Kit (libfund, libofund),

or the Classics Kit (libclass)

or the Universal Resource Class Heirarchy (liburch (think about it))

or the Objective-C Toolkit (libot, liboct)

or the Useful Class Kit (libuck)


---
Adam Fedor. CU, Boulder		    | Fudd's Law of Opposition: Push something  
fedor@boulder.colorado.edu (W)      |   hard enough and it will fall over. 
adam@bastille.rmnug.org (H,NeXTMail)|

From 
Return-Path: mccallum@cs.rochester.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id NAA28241; Mon, 8 Aug 1994 13:18:05 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id NAA20972; Mon, 8 Aug 1994 13:18:02 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA02408@albert.gnu.ai.mit.edu>; Mon, 8 Aug 94 12:30:46 -0400
Received: from cayuga.cs.rochester.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA20346; Mon, 8 Aug 94 12:30:22 EDT
Received: from slate.cs.rochester.edu (slate.cs.rochester.edu [192.5.53.101]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA20675; Mon, 8 Aug 1994 12:30:13 -0400
Received: from vein.cs.rochester.edu (vein.cs.rochester.edu [192.5.53.112]) by slate.cs.rochester.edu (8.6.9/G) with SMTP id MAA26660; Mon, 8 Aug 1994 12:30:11 -0400
Message-Id: <199408081630.MAA26660@slate.cs.rochester.edu>
To: rms@gnu.ai.mit.edu (Richard Stallman)
Cc: gnu-objc@prep.ai.mit.edu
Subject: Re: libgobjc name prefix 
In-Reply-To: Your message of "Sat, 06 Aug 94 01:17:47 EDT."
             <9408060517.AA09896@mole.gnu.ai.mit.edu> 
Date: Mon, 08 Aug 94 12:30:09 -0400
From: mccallum@cs.rochester.edu

I now agree with you that we shouldn't put "g" in the name of the
library.

I think I agree with you about not putting any prefix before the class
names in the library---at least I agree enough to start releasing the
library that way and see what kinds of conflicts we run into.

About merging libobjc and the class library: There is some resistance
to doing this, both on my part and others.  But libg++ does it, right?
i.e. you can't run any g++-compiled program without linking with the
G++ Class Library.  How did they come to this decision?

About automatically linking the the objc runtime library: I'd like it
to be analogous to g++.  It links automatically with the library it
needs.  It is also automatically set up to find the needed *.h files.
I'd also like things to be set up so that the compiler automatically
finds the class library *.h files.

Now we still need some names: (1) a name for the class library, (2) a
name for the directory that holds the class library *.h files, (3) a
prefix for a few functions and constants (like the version number of
the library).

Traditionally in Objective-C, *.h files for different packages are
included by using their parent directory name in the #include line,
not by putting the directory in the include search path.  So we get
things like
	#include <machkit/transport.h>
	#include <objc/Object.h>
	#include <appkit/View.h>

For this reason I would like (2) to be short.

I suppose we could also consider breaking with tradition and putting
the class library *.h file directory directly in the search path.
This would match your idea of the library as a "basic bag-of-tricks
library for a language [that] should not be treated like a specialized
library".  Also, the NULL string is very short.  :-)

It would, however, seem a little odd to need a prefix directory for
Object.h, but not for a more specialized class library object like
Dictionary.h.  This points toward a solution that I've wanted for
other reasons: move the Object class out of the runtime library and
into the class library.  NeXT's Object class is different from GNU's
Object class which is also different from NeXT's new NSObject
class---and people can create their own base class if they like.  One
particular Object class should not forced on the users as part of the
runtime.  Any comments?

I would also like (3) to be relatively short.  Long prefixes are a
pain.

It would be nice if (1) and (3) were the same, but it's not a
requirement for me.  If (2) is non-NULL, I would like it to be the
same as (3).

I haven't yet decided on using a NULL include directory or not.
Comments?

I would like the names to include the string "objc".

I've thought about using "objcc" (standing for OBJC Class library) for
(1) and (3).  The English name for the library is currently "The GNU
Objective-C Class Library".  Comments?

From
Return-Path: mccallum@cs.rochester.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id NAA28238; Mon, 8 Aug 1994 13:18:03 -0400
Received: from albert.gnu.ai.mit.edu (root@albert.gnu.ai.mit.edu [128.52.46.31]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id NAA20971; Mon, 8 Aug 1994 13:17:57 -0400
Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
	id <AA02499@albert.gnu.ai.mit.edu>; Mon, 8 Aug 94 12:38:07 -0400
Received: from cayuga.cs.rochester.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu-objc@albert.gnu.ai.mit.edu id AA20564; Mon, 8 Aug 94 12:37:53 EDT
Received: from slate.cs.rochester.edu (slate.cs.rochester.edu [192.5.53.101]) by cayuga.cs.rochester.edu (8.6.7/G) with ESMTP id MAA20749; Mon, 8 Aug 1994 12:37:51 -0400
Received: from vein.cs.rochester.edu (vein.cs.rochester.edu [192.5.53.112]) by slate.cs.rochester.edu (8.6.9/G) with SMTP id MAA26962; Mon, 8 Aug 1994 12:37:50 -0400
Message-Id: <199408081637.MAA26962@slate.cs.rochester.edu>
To: rms@gnu.ai.mit.edu (Richard Stallman)
Cc: gnu-objc@prep.ai.mit.edu
Subject: Re: libgobjc name prefix 
In-Reply-To: Your message of "Sat, 06 Aug 94 01:17:47 EDT."
             <9408060517.AA09896@mole.gnu.ai.mit.edu> 
Date: Mon, 08 Aug 94 12:37:49 -0400
From: mccallum@cs.rochester.edu

Some other ideas I forgot to mention:

Use simply "objc" for (2) and (3).  Make (1) different from (2) and
(3).

Rename the objc runtime library to "libobjcrt.a", and use "objc" for
all three.  Since the runtime library will be automatically linked in
by the compiler, users don't have to care about the name change.

Either of these fits well with your idea of the library as *basic to
GNU Objective C*, not a specialized library.

Comments?

From 
Return-Path: Kresten_Thorup@NeXT.COM
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id NAA28343 for <mccallum>; Mon, 8 Aug 1994 13:21:12 -0400
Received: from NeXT.COM (next.com [129.18.1.2]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id NAA21008 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 13:21:09 -0400
Received: from akvavit by oz.NeXT.COM (NX5.67e/NeXT0.1-Aleph-bf)
	id AA08572; Mon, 8 Aug 94 10:20:34 -0700
From: Kresten_Thorup@NeXT.COM (Kresten Krab Thorup)
Message-Id: <9408081720.AA08572@oz.NeXT.COM>
Received: by akvavit.next.com (NX5.67e/NX3.0X)
	id AA21927; Mon, 8 Aug 94 10:20:33 -0700
Date: Mon, 8 Aug 94 10:20:33 -0700
Received: by NeXT.Mailer (1.100.2)
Received: by NeXT Mailer (1.100.2)
To: mccallum@cs.rochester.edu
Subject: Re: libgobjc name prefix 
Cc: rms@gnu.ai.mit.edu (Richard Stallman), gnu-objc@prep.ai.mit.edu

I almost agree with Andrews last mail.  Use "objcc" for the class  
library, and "objcrt" (Geoff's idea) for the runtime library.  I  
don't think it is a good idea to keep all the headers in the same  
directory though.  The "objc/" directory should contain the basic  
NeXT-compatibel stuff, and then "objcc/" should be the class stuff.   
This would enable people to install your class stuff somewhere on a  
NeXT machine, without interfering with NeXT's "objc/" system  
directory.

Kresten

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA03773 for <mccallum>; Mon, 8 Aug 1994 15:44:03 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id PAA21934 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 15:44:00 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17020@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 15:43:51 -0400
Date: Mon, 8 Aug 94 15:43:51 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408081943.AA17020@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408081630.MAA26660@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    About merging libobjc and the class library: There is some resistance
    to doing this, both on my part and others.

No one suggested that--it was a misunderstanding.


From
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA03816 for <mccallum>; Mon, 8 Aug 1994 15:45:41 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id PAA21945 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 15:45:38 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17036@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 15:45:26 -0400
Date: Mon, 8 Aug 94 15:45:26 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408081945.AA17036@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408081630.MAA26660@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    Traditionally in Objective-C, *.h files for different packages are
    included by using their parent directory name in the #include line,
    not by putting the directory in the include search path.  So we get
    things like
	    #include <machkit/transport.h>

Does this convention apply even to general purpose things that every
program uses?

I am not arguing against it, just asking.

From 
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: libgobjc name prefix 
In-reply-to: Your message of "Mon, 08 Aug 94 15:45:26 EDT."
             <9408081945.AA17036@mole.gnu.ai.mit.edu> 
Date: Mon, 08 Aug 94 15:56:51 -0400
From: mccallum@cs.rochester.edu

rms@gnu.ai.mit.edu (Richard Stallman) writes:
>     Traditionally in Objective-C, *.h files for different packages are
>     included by using their parent directory name in the #include line,
>     not by putting the directory in the include search path.  So we get
>     things like
> 	    #include <machkit/transport.h>
> 
> Does this convention apply even to general purpose things that every
> program uses?

Yes, "#include <objc/Object.h>" is an example.  Actually, I'm not sure
if we should consider this an Objective-C tradition or a NeXT
tradition.  Does that effect our decision?

I don't feel very strongly about having or not having prefixing
directories. 

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id PAA03869 for <mccallum>; Mon, 8 Aug 1994 15:48:31 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id PAA21965 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 15:48:23 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17040@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 15:48:14 -0400
Date: Mon, 8 Aug 94 15:48:14 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408081948.AA17040@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408081630.MAA26660@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    It would, however, seem a little odd to need a prefix directory for
    Object.h, but not for a more specialized class library object like
    Dictionary.h.  This points toward a solution that I've wanted for
    other reasons: move the Object class out of the runtime library and
    into the class library.

I am not sure that is a good idea; but we could certainly move its
header file.

      NeXT's Object class is different from GNU's
    Object class

The code is different, of course, but I thought they were compatible.
Aren't they?  Shouldn't they be compatible?

     which is also different from NeXT's new NSObject
    class---and people can create their own base class if they like.

Sure, but they should not call it Object, so it does not affect
this issue.


From 
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: libgobjc name prefix 
In-reply-to: Your message of "Mon, 08 Aug 94 15:48:14 EDT."
             <9408081948.AA17040@mole.gnu.ai.mit.edu> 
Date: Mon, 08 Aug 94 16:31:28 -0400
From: mccallum@cs.rochester.edu

rms@gnu.ai.mit.edu (Richard Stallman) writes:
>       NeXT's Object class is different from GNU's
>     Object class
> 
> The code is different, of course, but I thought they were compatible.
> Aren't they?  Shouldn't they be compatible?

The GNU Object functionality is a superset of the NeXT Object
functionality.  NSObject is different from both, and has some nice
features that I want to incorporate into GNU's Object.  

The problem is in maintaining compatibility with the old NeXT Object.
I don't yet know for certain that the original NeXT Object and the new
NSObject have any conflicting demands, I'll have to look more at the
details.  Perhaps it's not worth worrying about until I know more.

>      which is also different from NeXT's new NSObject
>     class---and people can create their own base class if they like.
> 
> Sure, but they should not call it Object, so it does not affect
> this issue.

Yes, you're right.

I am now leaning towards using "objcc" as the library name, as the
directory prefix, and as the prefix for a few contants.

I'm still open to any feedback you might have.


From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id QAA05179 for <mccallum>; Mon, 8 Aug 1994 16:30:01 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id QAA22178 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 16:29:54 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17149@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 16:29:23 -0400
Date: Mon, 8 Aug 94 16:29:23 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408082029.AA17149@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408081956.PAA04158@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    I don't feel very strongly about having or not having prefixing
    directories. 

I don't either.

If we decide not to have them for basic things, then we should move
Object.h too.

From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id QAA05493 for <mccallum>; Mon, 8 Aug 1994 16:42:24 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id QAA22325 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 16:42:20 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17193@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 16:42:15 -0400
Date: Mon, 8 Aug 94 16:42:15 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408082042.AA17193@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408082031.QAA05213@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

I suggest `objects' as the library name?  It is much easier to say
than `objcc'.


From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id QAA05994 for <mccallum>; Mon, 8 Aug 1994 16:57:19 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id QAA22460 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 16:57:13 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17245@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 16:57:01 -0400
Date: Mon, 8 Aug 94 16:57:01 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408082057.AA17245@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
Subject: objcc

Another drawback of objcc is that it is too hard to distinguish it
from objc.  People will get them confused both in print and in speech.

It is important to pick a name that doesn't look or sound close to objc.
And it ought to be easy to say.


From 
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: libgobjc name prefix 
In-reply-to: Your message of "Mon, 08 Aug 94 16:42:15 EDT."
             <9408082042.AA17193@mole.gnu.ai.mit.edu> 
Date: Mon, 08 Aug 94 17:01:22 -0400
From: mccallum@cs.rochester.edu

rms@gnu.ai.mit.edu (Richard Stallman) writes:
> I suggest `objects' as the library name?  It is much easier to say
> than `objcc'.

My current preference is for the name to include the string "objc".

My reasoning:

For years in the Objective-C community this abbreviation has been
understood to mean "Objective-C" and been pronouced "Objective-C",
(very much in same way we pronouce "/usr/src" as "user source").  In
email, newsgroup articles, etc, people even write "objc" in the middle
of an English sentence to mean "Objective-C".

The name "objects" could be from any of the *many* object-oriented
languages.  The name "objc" is understood specifically to mean
"Objective-C".

The "objc" prefix has already been used extensively by NeXT and by
Kresten in his runtime for Objective-C related identifiers.  People
are used to seeing it, and they know what it means.


From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id RAA06289 for <mccallum>; Mon, 8 Aug 1994 17:08:33 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id RAA22519 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 17:08:29 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17310@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 17:08:19 -0400
Date: Mon, 8 Aug 94 17:08:19 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408082108.AA17310@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408082101.RAA06102@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    (very much in same way we pronouce "/usr/src" as "user source").

I don't.

    The name "objects" could be from any of the *many* object-oriented
    languages.

In practice, that doesn't matter.  People will think about this only
in conection with Objective C, so they won't get confused.

    The "objc" prefix has already been used extensively by NeXT and by
    Kresten in his runtime for Objective-C related identifiers.  People
    are used to seeing it, and they know what it means.

If I were arguing that `objc' would be confusing or unclear,
this would be a good refutation.  But it has no other relevance.

From 
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: libgobjc name prefix 
In-reply-to: Your message of "Mon, 08 Aug 94 17:08:19 EDT."
             <9408082108.AA17310@mole.gnu.ai.mit.edu> 
Date: Mon, 08 Aug 94 17:36:59 -0400
From: mccallum@cs.rochester.edu

I've maintained that variable naming is one of the most difficult
parts of programming.  That's certainly been true for me today.

I'm getting close to agreeing with your name "objects", but I still
have some concerns.

rms@gnu.ai.mit.edu (Richard Stallman) writes:
>     The name "objects" could be from any of the *many* object-oriented
>     languages.
> 
> In practice, that doesn't matter.  People will think about this only
> in conection with Objective C, so they won't get confused.

Aren't you afraid this name will conflict with some other programmer's
choice?  Since you can mix Objective C and C++ code in the same
executable, and even in the same source file, we at the very least
need to think about conflicts both in the Objective C community and
the C++ community.

I guess I feel a little guilty for claiming such a *general* name all
to ourselves.


From 
Return-Path: rms@gnu.ai.mit.edu
Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by slate.cs.rochester.edu (8.6.9/G) with ESMTP id RAA07222 for <mccallum>; Mon, 8 Aug 1994 17:49:24 -0400
Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by cayuga.cs.rochester.edu (8.6.7/G) with SMTP id RAA22720 for <mccallum@cs.rochester.edu>; Mon, 8 Aug 1994 17:49:17 -0400
Received: by mole.gnu.ai.mit.edu (5.65/4.0)
	id <AA17384@mole.gnu.ai.mit.edu>; Mon, 8 Aug 94 17:49:13 -0400
Date: Mon, 8 Aug 94 17:49:13 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-Id: <9408082149.AA17384@mole.gnu.ai.mit.edu>
To: mccallum@cs.rochester.edu
In-Reply-To: <199408082136.RAA06896@slate.cs.rochester.edu> (mccallum@cs.rochester.edu)
Subject: Re: libgobjc name prefix

    I guess I feel a little guilty for claiming such a *general* name all
    to ourselves.

There's nothing wrong with that.  In fact, if you don't do that,
you almost guarantee an ugly unpronounceable name.

`objects' is not the only good name.  You can come up with others
if you drop the idea of making it start with a prefix like `objc'
that makes it unpronounceable.


