www.delorie.com/gnu/docs/libobjects/libobjects_50.html

search

	Buy GNU books!

User's Guide to the GNU Objective-C Class Library

18.3 Questions

I would greatly appreciate your feedback on the questions below. Please email your thoughts to mccallum@gnu.ai.mit.edu.

• I want to put method names in texinfo indices, but the colons in the method names are interfering with info's notion of menu item names and node names. Help. Any ideas? (Kresten?)

• I need to read through al the enumState code again and clean it up. Perhaps we'd like an Iterator class to use as a wrapper around the enumState functionality? The NIH Class Library organizes things this way.

• Should we keep the -safe... enumeration methods? They sure do add a lot of clutter to the protocols. If we got rid of them people would have to alloc an Array, copy the contents, and free the Array themselves.

• What would people think about removing the ...Object methods, and just having the ...Element methods instead? It might be a bit more difficult to use, but it would reduce clutter significantly. The ...Element methods are more efficient to use anyway, since most ...Object methods are wrappers around ...Element calls. I'm not sure what I think we should do.

  Here's an idea: Define the ...Object methods as macros. But we need a new macro scheme that works for methods instead of functions. We would need something with the following functionality:

  #define [REC replaceObject: OLDOBJ with: NEWOBJ] \ ([REC replaceElement:(elt)(OLDOBJ) with:(elt)(NEWOBJ)].id_u)

  The issue of macros for methods has been mentioned in email found in the gnu-objc-issues archive, in the file `preprocessor'.

• It would be nice to have more error checking on the types going in and out of a collection. When some code tries to put a float into a collector initialized to hold integers, it would be nice to catch that. Perhaps just some macros that will do the appropriate checks? It would also be nice if elt's returned from methods were automatically casted to the correct type.

  It might be good to use something like this (from the gcc PROJECTS file):

  * A way of defining a structure containing a union, in which the choice of union alternative is controlled by a previous structure component. Here is a possible syntax for this. struct foo { enum { INT, DOUBLE } code; auto union { case INT: int i; case DOUBLE: double d;} value : code; };

  This has the disadvantage that now elt's will take up more than one word.

  What I would prefer is something more radical: Some efficient way to enable int's, float's to receive Objective-C messages. Then I wouldn't have to worry about any of these horrible elt typing issues; I wouldn't have to worry about all the ...Object ...Element method name duplication; I wouldn't have to worry about the inefficiency of having all the ...Object methods just be covers for the ...Element methods. Lots of other Objective-C code would find this useful too. It has the advantage of fixing the previous question also (about removing the ...Element ...Object method duplication). We need Objective-C objects that can live on the stack.

  For now, I've worked out a ObjC++ solution to this with constructors and casting operators. Now I'm just waiting for Kresten to finish ObjC++.

• Perhaps we should put more safety checks into LinkedList, BinaryTree, etc: Check that node is not already part of another collection (by checking that neighbor pointers are nil?) In method "insertObject:newObject after:oldObject" make sure that oldObject is a member of self. ...It seems that there is a lot of potential for nasty bugs with mistakes like these.

• HashTable.m (-initKeyDesc:valueDesc:capacity:) I tried to make it portable, but I didn't try very hard. Anyone want to send in fixes?

• I fixed -emptyCopy in all the subclasses, but the -emptyCopy scheme seems pretty fragile. How about calling -initFoo: inside -emptyCopy? This way we avoid having yet another method in which instance vars must be initialized to some consistent state. -allocCopy would never even get called. <<ObjC insiders: This is a less well-expressed version of what we've just been discussing in email.>>

• The situation with LinkedListNode and LinkedListEltNode, (and the analagous classes for BinaryTree's and RBTree's) are just crying out for multiple inheritance. Anyone have ideas that are prettier than my quick fix using #include ? Anyone have an alternate organization that doesn't need multiple inheritance?

• Somes classes, like RBTree, depend on a certain ordering of elements to maintain internal consistency. How should we define the behavior of methods whose names imply that the user can set the ordering of elements independent of these constraints? (like -appendElement: or -insertElement:atIndex: for instance). I see three possibilities:
  1. The methods do what they say. Give the user the power to override the default ordering.
  2. The methods do not do what they say, but call addElement: instead. This lets the class maintain its internal consistency, but it has the potential to be a bit confusing to the user. What would happen if the user sent a sort message to such a class, for instance?
  3. The methods trigger a -shouldNotImplement: error. This solution perhaps best expresses the reality of the situation, but it's a bit strange for a class to signal an error on a method which is in a protocol the class conforms to.
  Currently I'm using solution #1 (in most classes?).

• I created libobjects.texi by copying libg++.texi. Some of the text is taken verbatim. Is this a problem?

• If you don't like the organization of the documentation and you have suggestions for changes, please say so now, not after it's all been written.

• Does anyone really miss the ability to set the comparison function independent of the element encoding? If it's really important we can come up with ways to do this and still be able to archive comparison functions.

• Something like this needed? - elementDidChange: (elt*)elementPtr; Currently you have to remove, change, add, for some classes.

• I've been told that GNU filenames should be 14 chars or less. I don't want to abbreviate my classnames, but I think using .h @interface files with names different than the class name is even worse. ** I want to keep my unabbreviated filenames!! ** What to do, what to do... I can't believe that *all* GNU classnames will be limited to 12 characters forever and ever--disgusting.