🚀 go-pugleaf

In article <129@contel0> barton@contel0.UUCP (Matthew Barton - R+D Software eng) writes:
| 	Does anyone have any other suggestions for speed improvement,
| 	which are specific to the Objective-C language (as opposed to
| 	just general-purpose good-programming practices)?

The approach you outlined seems quite sound, and admirably researched.
I occasionally use another one that is based on the following terminology.

I think of Objective-C objects as providing chip-level objects on top of
a C substrate that has always provided block-level objects (subroutines)
and gate-level objects (macros).

Thus when designing something, I think as a hardware designer might,
at each step thinking about whether this might be best packaged as
a gate-level object, a block-level object, a chip-level object, etc.

For example, when building a time-critical Queue class, I decided
that for clients for whom enqueing/dequeueing might be time-critical,
a block-level (subroutine-based) interface should be provided in
addition to the conventional chip-level (message-based) interface
for clients for whom purity and polymorphism were preferable. So
my Queue class looks like this:

@interface Queue:ListBasedCollection
...
-enqueue:aQueueMember 
{
	return (id)enqueue((QUEUE*)self, (MEMBER*)aQueueMember); 
}
@end
EXPORT QUEUE* enqueue(QUEUE* aQueue; MEMBER* aQueueMember) { ... }

In other words, the enqueue() subroutine corresponds to a chip
designer who decides to package the chip's functionality, not
only as a chip, but also as a resuable cel. Clients outside
his own company would use the functionality through the chip-level
interface. By packaging his work not only as a chip, but also as
a block (a cel) would allow experts within his company to reuse
the functionality through the lower-level, more complicated,
more efficient, less pluggable block-level interface.
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482