Re: Class clusters - infinite loop?
Re: Class clusters - infinite loop?
- Subject: Re: Class clusters - infinite loop?
- From: Wade Tregaskis <email@hidden>
- Date: Mon, 27 Jun 2005 13:42:12 +1000
Perhaps a specific example would help. Most class clusters never
return self from their init methods - they allocate a new instance
of whichever specific hidden subclass they're going to use, and
release self. How then are you supposed to call [super init] (or
equivalent) in your subclass? You can't. Which means you
probably can't rely on any of the superclass behaviour.
Wah? He was talking about the init in the class cluster's common
superclass, in which it is probably a good idea to call super init:
- (id)initWithData:(NSData *)someData {
self = [super init];
[self release];
// look at the data
if([someData length] > 100) {
self = [[BigDataHolder alloc] initWithData:someData];
}
else {
self = [[SmallDataHolder alloc] initWithData:someData];
}
return self;
}
But now if you subclass that, you can't call that implementation of
initWithData, because it never returns self. That's my problem.
Sometimes it's an issue, sometimes it isn't (i.e. when there's a
separate, private method for doing actual initialisation).
A compromise which I'd be willing to accept is if there were
documented public methods for both the cluster initialisers/
constructors and the specific instances. That way if I'm subclassing
I can safely call the specific instance initialiser and avoid the
issue, while anyone using the class cluster can use the generic
initialisers.
There are issues with that - your subclass no longer benefits from
the extensibility offered by the class cluster, since it's no longer
opaque as to which class it uses, but I think that's probably
unavoidable. If you *really* *desperately* *absolutely* need that
cluster behaviour, you don't subclass it - use a delegate, or an
instance variable, whatever.
To reiterate my earlier example with NSOutputStream, what I wanted
to do was create a subclass of it which performs a cryptographic
operation on the data as it goes out - a SHA1 hash, for example.
Now, it seems NSOutputStream is a cluster with at least 3 private
subclasses for each of it's three modes of operation. I don't
want to subclass three private classes, or extend them with
categories. The may change in future. Also, I don't need the
redundancy. All I want is the documented public behaviour of
NSOutputStream.
Doesn't SHA1 need the entire dataset? Streams need to support
incremental reads and writes.
This doesn't sound like it should be a subclass of NSOutputStream
anyway, it should more like a pipe. You may want your SHA1'd data
to go to memory, a buffer or a file, or any other NSOutputStream
subclass.
SHA1 can operate on a stream... I think you'd be hard pressed to find
any digest algorithm which didn't; you're principally operating on
streams of data, which in many cases won't be buffered (in their
entirety, anyway).
For further background, I'm working on my Keychain framework, which
puts a nice ObjC interface on all the C/C++/whatever Security stuff
Apple provides (plus a few extras). At the moment you can easily
take the digest of some data using a category extension of NSData,
but that's no good if you can't buffer your entire data set. So, an
NSStream subclass seemed like the intuitive way to go (although at
this point I'm more than open to alternatives).
Unfortunately, NSStream and friends seem to be a dead-end, design
wise. What I would have done is have NSOutputStream and
NSInputStream be formal protocols. Subclasses of NSStream would
adopt them as appropriate. That way you could have sources, sinks
and processing streams, and produce nice little chains, and avoid
some of the cluster issues.
As it stands, I may just do that, and work in some kind of class
member compatibility for those who want to use my classes as
NSStreams. Gross, but I'm not aware of a better solution.
Wade Tregaskis (AIM/iChat, Yahoo & Skype: wadetregaskis, ICQ:
40056898, MSN: email@hidden, AV iChat & email:
email@hidden, Jabber: email@hidden)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden