Subject: Re: MiscString - Categories?

From: [email-masked] (Ernest Prabhakar)
Date: Mon, 27 Sep 1993 14:46:37 -0700

>>The string class stuff currently in the MiscKit looks nice,
>>but I think I'd like to see it broken up into a small heirarchy
>>of classes.

> Another possibility is splitting up the .m file into components
> to make them more manageable, but again it means more files.
> I'm not sure if it's possible to decide which sections get included
> or not.... if so, that is another possiblity - allow the programmer
> to decide which sections of code they want want to bring in.

Isn't this precisely what "Categories" are for?  The essential  
functionality is in the class; creeping features go into the  
categories.  Normally, the '.m' files get compiled into a library, and  
the user includes '.h' files for whichever methods he wants to call.   
For a developer wanting to use the kit in this application, he can  
start with the class, and then add whichever categories (both .h and .m  
files) he needs.

- Ernie P.
---
Ernest N. Prabhakar                  Caltech High Energy Physics
Member, League for Programming Freedom ([email-masked])
CaJUN President        NeXTMail:[email-masked]
"...and ourselves, your servants for Jesus sake." - II Cor 4:5b
#import <std/disclaimer.h>

---

From: [email-masked] (Don Yacktman)
Date: Mon, 27 Sep 1993 15:55:56 -0600

> Isn't this precisely what "Categories" are for?

This is kind of what I'm leaning toward right now.  There's no
doubt in my mind that the String class suffers from creeping
featuritis, but you'll also notice that for all the methods
I've added over time, I have never added instance vars.  That
means that most, if not all, of the methods would be just
fine in categories.  How should we break it down, though?  If
you make it too tiny, it's a pain to include all those files,
but if it's too granular, then you end up with a lot of extra
code...  So some sort of compromise needs to be discovered.

With everything else, I haven't had much time to give this
thought, even though I'm well aware of the problem, as Carl
pointed out in his message (which absolves me of repeating my
discussion with him, since he already did...).

Later,
-don