FIFOs.
FIFOs.
- Subject: FIFOs.
- From: "John C. Randolph" <email@hidden>
- Date: Mon, 20 Aug 2001 06:45:10 -0700
On Monday, August 20, 2001, at 06:20 AM, Ondra Cada wrote:
John,
John C. Randolph (JCR) wrote at Mon, 20 Aug 2001 05:59:03 -0700:
JCR> >I would really pledge to the very opposite: my point of view is
that
JCR> >cluttering Foundation with utterly unneeded classes whose
functionality
JCR> >is just a subset of others would not help anybody.
JCR>
JCR> First, a FIFO is not a subset of what the other container classes
do.
It is. See below.
JCR> Second, it's a suitable addition to Foundation, because it's
something
JCR> that a lot of people have to do over and over again.
Nope. The following code is NOT, repeat NOT worth a special API:
#define NSFIFOArray NSArray
// use addObject: to add an object
@implementation NSMutableArray (NSFIFOTotallyUnnecessaryCategory)
-firstObject { return [self objectAtIndex:0]; }
-returnAndRemoveFirstObject {
id val=[[self objectAtIndex:0] retain];
[self removeObjectAtIndex:0];
return [val autorelease];
}
@end
It is so simple and transparent that it is, actually, not worth the
category
I agree that such an inefficient FIFO as you describe isn't worth the
category.
Look, I've written my own perl-style -shift, -unshift: -push: and -pop
methods too, but
I can see that your idea of what a FIFO should do, and mine are quite
different.
I want a FIFO implemented as a proper thread-safe ring buffer that will
grow as necessary to prevent overflow, and avoid needless shuffling of
memory as your example will do. I want this FIFO to be writeable by one
thread while being read by another.
Sure, one can use an NSMutableArray as an inefficient, non thread-safe
FIFO, but that's not what I was talking about.
-jcr
For every complex problem there is an answer that is clear, simple, and
wrong. -- H L Mencken